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 96000

Article: 96000
Subject: Re: C to FPGA Tools (Impulse C and others) and necessary trig IP
From: fpga_toys@yahoo.com
Date: 27 Jan 2006 11:44:05 -0800
Links: << >>  << T >>  << A >>

Symon wrote:
> Hi Pete,
> There's a guy here on CAF who's something to do with FpgaC.
> http://fpgac.sourceforge.net/
> Perhaps you could ask him to help implement the COS function, he seems to be
> at a loose end! ;-)

Actually it would be a fun project, and down the line of where
we are headed long term anyway. The FpgaC project has
a way to go to be fully featured, but it seems that this project
could be done as a series of user written functions with little
trouble.

As far as being a loose end, I'll take that as a complement :)
Life is very disappointing when you sit around a wait for things
to happen. Stirring things up a little is sometimes required to
shake the cobwebs off that are holding everyone stuck in place.


Article: 96001
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m>
Date: Fri, 27 Jan 2006 12:51:34 -0800
Links: << >>  << T >>  << A >>
I am unfamiliar with the Atmel part in question but am quite certain 
that iMPACT is OK with instruction register lengths down to 2 bits 
(which is the minimum allowed by the standard).  My cursory examination 
of the Atmel data sheets indicates that the part has 2 pins that control 
   the test modes - a TST (which seems to enable some manufacturing 
modes so it must always be low) and the JTAGSEL (which seems to be 
temperamental in that a reset is required between toggles).  I'm 
wondering if the FPGA pins are connected to either of these pins and 
perhaps interfering with the boundary-scan chain during configuration? 
I'm suspicious of some interaction of that sort, if not between the FPGA 
and those pins, perhaps some other ones - or perhaps an interaction 
between the processor pins and PROG or the FPGA mode pins during 
configuration.

Idle thoughts...

Glad you have a work-around.

Antti Lukats wrote:
> "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag 
> news:88sCf.1959$wk5.1266@news02.roc.ny...
>> "Antti Lukats" <antti@openchip.org> wrote in message 
>> news:drd04j$iu7$01$1@news.t-online.com...
>>> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL
>>>
>>> attempt to configure FPGA with Impact, done not high configuration status 
>>> register = 0000
>>> attempt to program PLD seems to stall forever clicking abort and waiting 
>>> makes impact again responsive with failure to program
>>>
>>> changing the BSDL file makes the chain order to get messed, attempt to re 
>>> order the device by mouse drag and drop causes impact to self terminate.
>>>
>>> are there any issues with non Xilinx device in JTAG chain with impact 
>>> 8.1?
>>>
>>> any help really welcome, I do not have time to open a webcase as I must 
>>> have the board up and running til early next week.
>>>
>>> (the new bugs are entered in bugtrackter http://bugs.xilant.com )
>>>
>>> -- 
>>> Antti Lukats
>>
>> I don't know why I had problems but we worked around them.  The Spartan-3 
>> on my board was the first in the JTAG chain followed by 4 other non-Xilinx 
>> devices.  On the new rev of board we connected the FPGA so it could be 
>> isolated from the other devices for Chipscope-like debug (Synplify's 
>> Identify product) by swapping a couple resistors.  Without the isolation 
>> from the chain, when I tried to get the debugger to communicate the board 
>> would reset.  There may have been troubles with 1) another chip resetting 
>> the system when toggled through the jtag sequence with or without TRST 
>> applied properly to that device or 2) unexpected voltages on the soft 
>> reset signal sourced by the FPGA causing a system reset.  Bottom line: I 
>> couldn't get the JTAG port up & running for debug on the first generation 
>> of board. Thankfully the Identify tool allows a "custom" port that's a 
>> JTAG emulator that I ported out to 4 test points.
>>
> thanks John,
> 
> well I have a workaround also, the chip that makes impact to freeze is
> Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at 
> powerup)
> one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary scan) 
> 3 bit IR
> length. So if the ARMice is chain all is OK. if the ARM boundary scan then 
> impact freezes.
> 
> So my guess is that Impact can not handle JTAG devices with IR register 
> lenght less than 4
> but I may be wrong of course.
> 
> Anyway the workaround for us was to remove the pullup on JTAGSEL of the ARM 
> SAM
> and those make the ARM IR register 4 bit long, then impact can work without 
> problems
> 
> 

Article: 96002
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Brian Davis" <brimdavis@aol.com>
Date: 27 Jan 2006 13:07:26 -0800
Links: << >>  << T >>  << A >>
johnp wrote:
>
> I don't see any documentation on the DIFF_OUT buffers you mention.
> Do you have any info on them or pointers to doc?
>
All the V2-ish differential input buffers have a complementary output
available, that can be used to create a 180 degree clock without
needing a DCM.

 These can also be used just to invert a differential input without
needing any other logic (or board cuts & jumps).

Look at the DIFFS component in fpga_editor to see what's going on;
besides the normal 'phantom' route from the DIFFS to the DIFFM,
there's also a route from the DIFFM to a differential receiver in the
DIFFS that outputs the complement signal.

 I first spotted these when they showed up in early versions of
XAPP622 as a hard macro.

  Support & tool bugs for these have varied version to version,
see Answer Record 21958 for recent problems.

 I've banged into various other problems in using them over the years;
if I get a chance this weekend, I'll try to dig up some old webcase
code showing how to create one out of two normal IBUF{G}DS's as
a work around.

These can be used on regular IOB inputs as well as global clock
inputs, but you've generally needed to LOC the global input buffer
and bufg's to allowed sites to get this to work.

 search for
  ibufgds_diff_out
  ibufds_diff_out

Brian


Article: 96003
Subject: Re: XilNet server data streaming problem from PPC
From: Johan Bernspang <NOSPAM_johbe_NOSPAM_@foi_NOSPAM.se>
Date: Fri, 27 Jan 2006 21:46:54 GMT
Links: << >>  << T >>  << A >>
> Without knowing the particular package you use, but having
> written a fullblown tcp/ip implementation for PPC, I would say
> that either your client is messed up (does not send the right
> ack segments so you have to manually send them) or, more
> likely, some of the segments the server sends after the first
> one get lost and thus the client never sends an ACK.
> If the IP layer is doing fragmentation/defragmentation, this
> could be a place to look at. Also, I have encountered similarH
> behaviour when I have had simply physical layer problems
> (too many lost packets), but in most cases the TCP retransmission
> would take care of that.
> Hope this is of some help...
> 
> Dimiter
> 
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
> 
> http://www.tgi-sci.com
> ------------------------------------------------------
> 

Hi Dimiter and thanks for your input,

The client is made in .NET by a colleague, and I don't think that the 
socket package is behaving badly. I have also tried to connect with a 
terminal program to my server as well with the same results.

I have been sniffing the communication with Etherreal and what happens 
is that the server starts listening on a certain port (i.e. accept is 
polled until a client connects). The initial SYN and ACKs are carried 
out correctly and the server is waiting for the client to send it some 
sort of commando. This is done in the same loop as accept on the 
established connection. When the client tells the server to start 
sending data a xilsock_send command is added to the loop. That is, each 
looping does first an accept to check for packets, second a parsing of 
the available data (if any), and finally a sending of data. In Etherreal 
I have seen that the first data packet is sent successfully followed by 
an ACK from the client, the second data packet is sent too (with the 
correct seqno and ackno), but the ACK to that data packet is a duplicate 
of the first ACK (thus with the wrong ackno). The server then tries to 
retransmit the failing packet without success... I wouldn't be surprised 
if my server application is lacking some feature, but I really can't see 
what it is.

Johan (from the living room couch on a Friday night)

-- 
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------


Article: 96004
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 27 Jan 2006 23:39:11 +0100
Links: << >>  << T >>  << A >>
"Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im 
Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com...
>I am unfamiliar with the Atmel part in question but am quite certain that 
>iMPACT is OK with instruction register lengths down to 2 bits (which is the 
>minimum allowed by the standard).  My cursory examination of the Atmel data 
>sheets indicates that the part has 2 pins that control the test modes - a 
>TST (which seems to enable some manufacturing modes so it must always be 
>low) and the JTAGSEL (which seems to be temperamental in that a reset is 
>required between toggles).  I'm wondering if the FPGA pins are connected to 
>either of these pins and perhaps interfering with the boundary-scan chain 
>during configuration? I'm suspicious of some interaction of that sort, if 
>not between the FPGA and those pins, perhaps some other ones - or perhaps 
>an interaction between the processor pins and PROG or the FPGA mode pins 
>during configuration.
>
> Idle thoughts...
>
> Glad you have a work-around.
>
yes I have a workaround that is ok so far, but for production test I need
correct solution too.

JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL
value by reprogramming the PLD, afer that impact just frozed while trying to 
reporgram the PLD.

so no matter the the reason for the fail, there is some sort of bug with 
impact as any kind of
wrong behaviour of the JTAG chain during programming should not cause impact 
to freeze.

my guess about  the 3 IR bits not supported was based on fact that as soon 
as reverted
the ARM into ICE mode with longer IR register everything started to work 
again. the
ARM has been unprogrammed all the time, only change to revert the chain 
useable
was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the 
connection
to PLD can not change the scan chain config once powered.

well FPGA PROG_B is also connected to the PLD, but it should not matter as 
the
signal that made the difference was JTAGSEL on ARM, no matter the FPGA
connections it should not prevent the PLD from being programmed - as long
as ARM IR chain doesnt chain its length during runtime. I will investigate 
it
a little more when the board is otherwise fully tested.

Antti










Article: 96005
Subject: Lattice high end FPGAs to be announced soon
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 27 Jan 2006 23:52:02 +0100
Links: << >>  << T >>  << A >>
Hi all

Lattice is close to have some of the new FPGA products to be announced
some of them in the next few weeks time (probably at embedded in Nurnberg 
already)
no details known but something in the range of Virtex-4 is coming
(on high speed SERDES there are no immediate plans for support over 6Gbit)

MachXO is now all family in production, to my surprise (or maybe I had 
forgotten)
the full MacXO family is available in super compact 0.5mm pitch BGA 8 by 8 
mm

thats really neat, 8by8mm (only 1m larger then the CSP48 !), single supply 
1.8 - 3.3
up to 2 PLL and 3 BRAMs, distributed RAM, and fabric faster than the 
LatticeXP

also coming are are sub 3 (and even sub 2) USD low cost small package 
versions
of the power supply monitor and supervisory circuits

Antti 



Article: 96006
Subject: Re: Lattice high end FPGAs to be announced soon
From: fpga_toys@yahoo.com
Date: 27 Jan 2006 15:00:17 -0800
Links: << >>  << T >>  << A >>

Antti Lukats wrote:
> Lattice is close to have some of the new FPGA products to be announced
> some of them in the next few weeks time (probably at embedded in Nurnberg
> already)
> no details known but something in the range of Virtex-4 is coming
> (on high speed SERDES there are no immediate plans for support over 6Gbit)

Wow ... totally cool. This market is going to have lots of viable
players soon :)


Article: 96007
Subject: Re: XilNet server data streaming problem from PPC
From: "dp" <dp@tgi-sci.com>
Date: 27 Jan 2006 15:01:33 -0800
Links: << >>  << T >>  << A >>
Johan Bernspang wrote:
> ......  In Etherreal
> I have seen that the first data packet is sent successfully followed by
> an ACK from the client, the second data packet is sent too (with the
> correct seqno and ackno), but the ACK to that data packet is a duplicate
> of the first ACK (thus with the wrong ackno). The server then tries to
> retransmit the failing packet without success... I wouldn't be surprised
> if my server application is lacking some feature, but I really can't see
> what it is.
>
> Johan (from the living room couch on a Friday night)
>

Hi Johan,

this really sounds like the segment you call "second packet" is either
bad when being sent or lost at the receiving side, thus the server
retransmits. Since it does have the right seq and ack numbers,
the reason must be elsewhere - could be the tcp checksum,
IP header checksum, some other bad field, damaged IP, misrouted,
you name it. Please feel free to contact me priavately if you feel like
it,
I'd be happy to look into the IP packet exchange (but I do think
it will just take you another hour or so of thorough
inspection and you'll figure it out, these things are bulky yet
pretty straight forward).

Dimiter

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

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


Article: 96008
Subject: Re: HOW CAN I USE OPB EMC
From: shane <shanel2k4@yahoo.com>
Date: Fri, 27 Jan 2006 15:57:08 -0800
Links: << >>  << T >>  << A >>
hi

Thanks for replying

iam using microblaze for first time so please bear with my questions

iam using data width for flash device as 8 but does opb emc support data width matching for flash devices?

if it does support, updating the settings of system.mhs file takes care of it or do i need to change any other settings

wat values should i use for these parameters C_THZCE_PS_MEM_0, C_TWP_PS_MEM_0 ,C_TCEDV_PS_MEM_0, C_TAVDV_PS_MEM_0, C_TWC_PS_MEM_0

Article: 96009
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 28 Jan 2006 01:06:42 +0100
Links: << >>  << T >>  << A >>
Sean Durkin schrieb:

> The signal I get as output from the IBUFDS I can feed into an ISERDES.
> Since one ISERDES can only give me 6 bits in parallel, I need to use two
> ISERDES in Master-/Slave-mode, but then they can only give me 10bits
> instead of the 12 I actually get from the ADCs. So it's not going to
> work that way.

Why? An ethernet frame is hundreds of bits and you can still receive it
with an ISERDES.

Use a 1:6 serdes and continue to process your data stream in chunks of
6-bit at a convenient rate of 80 MHz. You can add logic in the
FPGA-fabric that immediately converts the stream to 12-bits at 40MHz.
But probably you get a smaller circuit when you do all your signal
processing 6-bit-nibble serial at 80MHz.

This issue came up in this newsgroup a few times before. Somehow
everybody immediatly recognizes that a 16-bit entity can be split up
into two bytes of 8-bits. But as soon as the numbers change a  little
apparently it becomes less obvious.

Kolja Sulimma

Article: 96010
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m>
Date: Fri, 27 Jan 2006 16:08:06 -0800
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im 
> Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com...
>> I am unfamiliar with the Atmel part in question but am quite certain that 
>> iMPACT is OK with instruction register lengths down to 2 bits (which is the 
>> minimum allowed by the standard).  My cursory examination of the Atmel data 
>> sheets indicates that the part has 2 pins that control the test modes - a 
>> TST (which seems to enable some manufacturing modes so it must always be 
>> low) and the JTAGSEL (which seems to be temperamental in that a reset is 
>> required between toggles).  I'm wondering if the FPGA pins are connected to 
>> either of these pins and perhaps interfering with the boundary-scan chain 
>> during configuration? I'm suspicious of some interaction of that sort, if 
>> not between the FPGA and those pins, perhaps some other ones - or perhaps 
>> an interaction between the processor pins and PROG or the FPGA mode pins 
>> during configuration.
>>
>> Idle thoughts...
>>
>> Glad you have a work-around.
>>
> yes I have a workaround that is ok so far, but for production test I need
> correct solution too.
> 
> JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL
> value by reprogramming the PLD, afer that impact just frozed while trying to 
> reporgram the PLD.
> 
> so no matter the the reason for the fail, there is some sort of bug with 
> impact as any kind of
> wrong behaviour of the JTAG chain during programming should not cause impact 
> to freeze.
> 
> my guess about  the 3 IR bits not supported was based on fact that as soon 
> as reverted
> the ARM into ICE mode with longer IR register everything started to work 
> again. the
> ARM has been unprogrammed all the time, only change to revert the chain 
> useable
> was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the 
> connection
> to PLD can not change the scan chain config once powered.
> 
> well FPGA PROG_B is also connected to the PLD, but it should not matter as 
> the
> signal that made the difference was JTAGSEL on ARM, no matter the FPGA
> connections it should not prevent the PLD from being programmed - as long
> as ARM IR chain doesnt chain its length during runtime. I will investigate 
> it
> a little more when the board is otherwise fully tested.
> 
> Antti
> 

Hmm.  Which PLD is involved here?  I'm suspicious that iMPACT is not 
actually frozen but just taking a really long time to fail.  If it is a 
9500/XL/XV then these devices use polling to indicate when programming 
(or erasure) is complete.  The device responds with a status to iMPACT 
to indicate success or failure.  Some failure statuses mean keep trying 
- just wait longer.  The wait time increase can quickly increase to 
minutes in certain failure situations.  I am speculating that the PLD 
mucks with JTAGSEL doing something horrible to the boundary-scan chain, 
making the output look like the status that says "keep trying - just 
wait longer" and then you end up with this apparent "freeze".  Bad 
behavior.  Should fail more elegantly if that's what happening.  That's 
my theory, anyway.

> 
> 
> 
> 
> 
> 
> 
> 

Article: 96011
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 28 Jan 2006 13:18:24 +1300
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> my guess about  the 3 IR bits not supported was based on fact that as soon 
> as reverted
> the ARM into ICE mode with longer IR register everything started to work 
> again. 

.. perhaps the Atmel device itself has Bypass problems in the other mode ?

-jg


Article: 96012
Subject: Re: Lattice high end FPGAs to be announced soon
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 28 Jan 2006 13:25:32 +1300
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> Hi all
> 
<snip>
> also coming are are sub 3 (and even sub 2) USD low cost small package 
> versions
> of the power supply monitor and supervisory circuits

  These needed to come down in price - at the silly prices they were,
they were never going to hit mass support - just the odd VHDL designer 
who was unable to get a small uC and a couple of FETs to do the same thing.
  The newest tiny system uC, like the Tiny2313, newest ST7 lite, and
Atmel LP216, are all in the 80c region, and you keep getting more for
your 80-90c....

  All Lattice needs now, is to work out how to turn a profit :)

-jg


Article: 96013
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Erik Widding" <widding@birger.com>
Date: 27 Jan 2006 16:28:45 -0800
Links: << >>  << T >>  << A >>

Sean Durkin wrote:
>
> The signal I get as output from the IBUFDS I can feed into an ISERDES.
> Since one ISERDES can only give me 6 bits in parallel, I need to use two
> ISERDES in Master-/Slave-mode, but then they can only give me 10bits
> instead of the 12 I actually get from the ADCs. So it's not going to
> work that way.
>

Use the ISERDES setup you describe here to get 6 bits at a time.
Really quick pseudo code for a solution:

   signal left : std_logic_vector ( 5 downto 0);
   signal sample : std_logic_vector ( 11 downto 0);

   if ( falling_edge( sample_clock ) ) then
      left <= ISERDES_out(5 downto 0);
   end if;

   if ( rising_edge( sample_clock ) ) then
      sample <= left && ISERDES_out(5 downto 0);
   end if;

Sample clock needs to be properly phased to the ISERDES output, and a
timing constraint with 1/2 the period of sample_clock is placed between
ISERDES_out and the two destination registers.  The tools will take it
from here.


Regards,
Erik.

---
Erik Widding
President
Birger Engineering, Inc.

 (mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
  (fax) 617.695.9234
  (web) http://www.birger.com


Article: 96014
Subject: Re: EDK 8.1 ... delay
From: Eric Smith <eric@brouhaha.com>
Date: 27 Jan 2006 16:31:27 -0800
Links: << >>  << T >>  << A >>
John Adair wrote:
> EDK 8.1 is available from late last week to existing customers by the 
> download mechanism.

I just spoke to someone in Xilinx Customer Service, and she said that
although they had expected the official release of EDK 8.1 to occur this
past Monday, that apparently it did not, and she's not sure when it will
be.

The same thing happened with ISE 8.1; some customers were able to
download it before the official release, but others were not.

It seems reasonable to expect that the official release will occur
soon.

Eric

Article: 96015
Subject: Re: ISE8.1 on Linux, first impressions
From: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Date: Sat, 28 Jan 2006 00:37:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
hutzelbutz <joachim.becker@imtek.uni-freiburg.de> wrote:

> However, the command "hostid" gives the right value. So I did " sudo
> hostname > /etc/hostid" to create the file and voila: ISE starts in 5
> seconds.

I hope for Xilinx that it is possible to configure this filename.

It is clearly unacceptable that a (more or less) simple userland
application needs a system-wide configuration file. I agree
for daemons or default-overrides like /etc/opera6rc, but
not for a tool which might run without uid-0-interaction
at all.

Whoever has insisted on this filename should go back to
the 90th and code Win95-applications when there was still
no need to divide into user-related stuff (configuration,
save files) and system installation.

In other words: put your xilinx.ini in the windows directory ;)

SCNR ;)

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Kein Kind ass das Pilzgericht, nur der Juergen, der muss wuergen.

Article: 96016
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Brian Davis" <brimdavis@aol.com>
Date: 27 Jan 2006 16:45:44 -0800
Links: << >>  << T >>  << A >>
Symon wrote:
>The key insight is to  use a latch (NOT a FF) to align the clock enables
>in the rising and falling edge clock domains. The latches are fast enough
>to meet the timing way  beyond 480M, my stuff is working great at 622M.

Alas, I swore off Xilinx latches after the Great Latch Inversion of '00

Brian

p.s.
  Actually, it's not the actual latches I distrust; it's the software
guys configuring the latches, having to interpret the latch enable
sense when it's not properly documented in the datasheet.

GoogleGroups "CLB latch clock inversion"

from latch_bug1.txt:
:   For an active low latch in an EDIF input file, you get
: the following results when tracing the clock signal through
: the tool flow:
:
:  tool stage       XC4000EX derived     Virtex Derived
: -------------------------------------------------------
:  EDIF in          active low           active low
:  MAP out          CLK:CLKNOT           CLK:CLK
:  EPIC display     dot clock            normal clock
:  SIMPRIM model    X_INV -> X_LATCH     X_INV -> X_LATCH
:  real HW          transparent low      transparent low
:
:  note: X_LATCH SIMPRIM models are transparent high


Article: 96017
Subject: Re: Spartan-3 Starter Board
From: Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com>
Date: Sat, 28 Jan 2006 01:12:07 GMT
Links: << >>  << T >>  << A >>
Hi Paul,

Assuming that you have a personal project that utilizes PCI bus, I will 
recommend BDS XPCI PCI IP core we have developed.
BDS XPCI PCI IP core is a Xilinx (TM) LogiCORE (TM) PCI compatible PCI 
IP core.
We offer this PCI IP core for as little as $100 for non-commercial, 
non-profit, personal use.
For more information, visit http://www.bracedesignsolutions.com.


Kevin Brace


Paul Marciano wrote:
> John Adair wrote:
> 
>>You might want to have a look at our product Raggedstone1. It has the much
>>larger XC3S400-4FG456C part fitted. Programming cable is included and card
>>can be used in a PCI slot or stand-alone with the optional PCI I/O Header.
>>Details here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html.
> 
> 
> As a learner and experimenter I like the look of that board, but how
> much does the Xilinx PCI core for the Spartan 3 cost?
> 
> Paul.
> 


-- 
Brace Design Solutions
Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available 
for as little as $100 for non-commercial, non-profit, personal use.
http://www.bracedesignsolutions.com

Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.

Article: 96018
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m>
Date: Fri, 27 Jan 2006 17:29:17 -0800
Links: << >>  << T >>  << A >>
The PLD pins float during programming. Depending on the CPLD, it is 
typically pulled high, weakly, while the device is being programmed. 
You might want to install a strong pull-up on the JTAGSEL to hold it 
high during configuration and see if that helps things.  If JTAGSEL 
floats low, you will be hosed - it appears.

Again, not knowing which Atmel device you are using you may also find 
this instructive:

http://www.atmel.com/dyn/products/faq_card.asp?faq_id=780


Neil Glenn Jacobson wrote:
> Antti Lukats wrote:
>> "Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> 
>> schrieb im Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com...
>>> I am unfamiliar with the Atmel part in question but am quite certain 
>>> that iMPACT is OK with instruction register lengths down to 2 bits 
>>> (which is the minimum allowed by the standard).  My cursory 
>>> examination of the Atmel data sheets indicates that the part has 2 
>>> pins that control the test modes - a TST (which seems to enable some 
>>> manufacturing modes so it must always be low) and the JTAGSEL (which 
>>> seems to be temperamental in that a reset is required between 
>>> toggles).  I'm wondering if the FPGA pins are connected to either of 
>>> these pins and perhaps interfering with the boundary-scan chain 
>>> during configuration? I'm suspicious of some interaction of that 
>>> sort, if not between the FPGA and those pins, perhaps some other ones 
>>> - or perhaps an interaction between the processor pins and PROG or 
>>> the FPGA mode pins during configuration.
>>>
>>> Idle thoughts...
>>>
>>> Glad you have a work-around.
>>>
>> yes I have a workaround that is ok so far, but for production test I need
>> correct solution too.
>>
>> JTAGSEL is connected to PLD, everything was fine until I changed the 
>> JTAGSEL
>> value by reprogramming the PLD, afer that impact just frozed while 
>> trying to reporgram the PLD.
>>
>> so no matter the the reason for the fail, there is some sort of bug 
>> with impact as any kind of
>> wrong behaviour of the JTAG chain during programming should not cause 
>> impact to freeze.
>>
>> my guess about  the 3 IR bits not supported was based on fact that as 
>> soon as reverted
>> the ARM into ICE mode with longer IR register everything started to 
>> work again. the
>> ARM has been unprogrammed all the time, only change to revert the 
>> chain useable
>> was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the 
>> connection
>> to PLD can not change the scan chain config once powered.
>>
>> well FPGA PROG_B is also connected to the PLD, but it should not 
>> matter as the
>> signal that made the difference was JTAGSEL on ARM, no matter the FPGA
>> connections it should not prevent the PLD from being programmed - as long
>> as ARM IR chain doesnt chain its length during runtime. I will 
>> investigate it
>> a little more when the board is otherwise fully tested.
>>
>> Antti
>>
> 
> Hmm.  Which PLD is involved here?  I'm suspicious that iMPACT is not 
> actually frozen but just taking a really long time to fail.  If it is a 
> 9500/XL/XV then these devices use polling to indicate when programming 
> (or erasure) is complete.  The device responds with a status to iMPACT 
> to indicate success or failure.  Some failure statuses mean keep trying 
> - just wait longer.  The wait time increase can quickly increase to 
> minutes in certain failure situations.  I am speculating that the PLD 
> mucks with JTAGSEL doing something horrible to the boundary-scan chain, 
> making the output look like the status that says "keep trying - just 
> wait longer" and then you end up with this apparent "freeze".  Bad 
> behavior.  Should fail more elegantly if that's what happening.  That's 
> my theory, anyway.
> 
>>
>>
>>
>>
>>
>>
>>
>>

Article: 96019
Subject: Debugging Spartan3 slave serial configuration
From: "Yaju Nagaonkar" <yaj_n@hotmail.com>
Date: 27 Jan 2006 17:33:33 -0800
Links: << >>  << T >>  << A >>
I am not yet done with my debugging yet, but thought would find out if
anyone out has experimented with slave serial configuraiton of
Spartan3.

Here is the setup on my PCB board.

The HSWAP_EN is tied to ground. The mode pins are floating.
An Atmega128 running at 5V has mapped to it the configuration signal
I/O of the FPGA. The PROG_B, INIT, CCLK, DIN. A series resistor(300ohm)
is connected between the DIN (FPGA 3.3V)and Atmega128(5V).

I can configure the FPGA from a JTAG port without changing the mode
pins.

I configure(via JTAG) the FPGA to run a continuous loop to blink LEDs.
Then my Atmega drives the PROG_B signal low, which resets the FPGA. The
INIT line is then checked and for some reason(using a Oscope) I have
not been able to see the INIT line go low at all.

After checking the INIT line, the atmega drives the CCLK low.
The atmega128 reads one byte from the flash and then unpacks each byte
and toggles the DIN signal according to the byte.

The sequence for the 8 bits  is as follows:

CCLK_LO()
toggle DIN(LSB)
CCLK_HI()
toggleDIN(LSB)

CCLK_LO()
toggle DIN(LSB+1)
CCLK_HI()
toggle_DIN(LSB+1)

and so on.

I have counter which keeps track of the bytes,which is 212393 bytes for
a Spartan3XC3S400. After counter expires, I toggle the CCLK a few more
time (as said in earlier discussions on this fourum).


I am not sure why the DONE bit is not going high?????

Any ideas?


Article: 96020
Subject: Re: C to FPGA Tools (Impulse C and others) and necessary trig IP
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Sat, 28 Jan 2006 16:32:27 +1300
Links: << >>  << T >>  << A >>
I think you are taking the wrong approach.  I'm sure you can get the C code
running.  But in reality if you have to implement sin/cos & sqrts, then the
C code will be far from optimal, and you might need a vertex to do the job
of a Spartan

Simon

"Pete Hudson" <pete.hudson@baesystems.com> wrote in message
news:1138358605.349842.85640@z14g2000cwz.googlegroups.com...
> I have been presented with a c program to implement on an fpga.
> I am investigating the possible processes/tools I could employ rather
> than a straight rewrite in VHDL.
>
> Current candidates are:
>
> Impulse C
> Handel-C
> Xilinx System Generator
>
> The algorithm is littered with sin cos sqrt & divides. So I expect that
> I require some of the xilinx IP cores that come with my ISE tool.
> (That's why XSG is getting a look in)
>
> Q. How do I implement this algorithm's cos functions (for example) in
> Impulse C so that it is represented in the resultant HW?
>



Article: 96021
Subject: Re: XilNet server data streaming problem from PPC
From: kd (kdfake@spam.com)
Date: 28 Jan 2006 05:13:55 GMT
Links: << >>  << T >>  << A >>
Hi

Yeah had the same problem with that library. I dont think they have 
any interest in fixing it either. So I use lwip now. That had bugs 
too, Xilinx bugs, but they have sorted it out now.


-- 
----------------------------------------------
Posted with NewsLeecher v3.5 Beta 2
 * Binary Usenet Leeching Made Easy
 * http://www.newsleecher.com/?usenet
----------------------------------------------


Article: 96022
Subject: Connection between FSL and XCL
From: "Marco T." <marc@blabla.com>
Date: Sat, 28 Jan 2006 09:59:31 +0100
Links: << >>  << T >>  << A >>
Hallo,
Is it possible to connect a FSL peripheral to a XCL channel of Xilinx 
Multi-Channel Sdram Controller?

I would read data from memory and send it out the fpga.

-- 
Marco 



Article: 96023
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: Sean Durkin <smd@despammed.com>
Date: Sat, 28 Jan 2006 10:04:42 +0100
Links: << >>  << T >>  << A >>
Kolja Sulimma schrieb:
> Why? An ethernet frame is hundreds of bits and you can still receive it
> with an ISERDES.

> Use a 1:6 serdes and continue to process your data stream in chunks of
> 6-bit at a convenient rate of 80 MHz. You can add logic in the
> FPGA-fabric that immediately converts the stream to 12-bits at 40MHz.
> But probably you get a smaller circuit when you do all your signal
> processing 6-bit-nibble serial at 80MHz.

> This issue came up in this newsgroup a few times before. Somehow
> everybody immediatly recognizes that a 16-bit entity can be split up
> into two bytes of 8-bits. But as soon as the numbers change a  little
> apparently it becomes less obvious.

That's not the problem.

The thing is that the ADC sends out, along with the data, a fast clock
and a 6x slower clock. If you run the ADC at 70MHz, it sends back a
420MHz clock and a 70MHz clock. The whole thing is designed so you use
the 420MHz to clock some sort of deserializing-circuit and the 70MHz to
clock out the parallel data and do your processing. So that's the
"intended" way to handle this, and of course you'd first look for a way
to do it with what you're provided with.

Now, since one single ISERDES doesn't handle DDR, it would have to be
run at 840MHz, plus I'd need to waste a DCM to double the clock (can
they even get up to 840MHz?) I get from the ADC. No way. Alternatively,
I could use two ISERDES in Master-/Slave-Mode (then they can handle DDR)
to output two 6bit-nibbles, as you suggested. But to get these out, I'd
have to have a 140MHz clock, which I don't have. Again, waste a DCM to
generate it. And since I normally have 4 of those ADCs hooked up to one
FPGA, that's 4 DCMs gone already, in addition to the 4 I need to do
phase-shifting anyway. That's 8 total, which is probably every single
one available in the devices I have available. Again, no way.

The whole point of using the ISERDES in the first place is to save on
DCMs, clock nets and hand-placed components, to make do with what is
readily available.

I still don't see where the ISERDES would make anything easier.

cu,
Sean

Article: 96024
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 28 Jan 2006 10:05:16 +0100
Links: << >>  << T >>  << A >>
"Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im 
Newsbeitrag news:drehdt$ngt8@cliff.xsj.xilinx.com...
> The PLD pins float during programming. Depending on the CPLD, it is 
> typically pulled high, weakly, while the device is being programmed. You 
> might want to install a strong pull-up on the JTAGSEL to hold it high 
> during configuration and see if that helps things.  If JTAGSEL floats low, 
> you will be hosed - it appears.
>
> Again, not knowing which Atmel device you are using you may also find this 
> instructive:
>
> http://www.atmel.com/dyn/products/faq_card.asp?faq_id=780
>

Hi Neil,

hmmm - the JTAGSEL is only captured at powerup later level changes (PLD pins 
floating)
should not cause any change or trouble.

also I would have expected JTAG problems in the case where ARM-ICE JTAG is 
in chain
but it is the other way around, when ICE is in chain all works, when ARM 
boundary scan is
in chain then the chain is scanneable, but impact fails really strange.

I would be happy to leave the JTAGSEL=0 and ARM in ICE mode, but the 
manufacturer
of the board wants to access boundary scan on all devices that support it, 
this includes the ARM

and yes the PLD is XC9572XL, but complete freeze (or what seems as complete 
freeze) could
still be prevented, ie the 'abort' button should be responsive also during 
the wait periods

Antti





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