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 95975

Article: 95975
Subject: Re: Multichannel Opb Memory Controller question
From: "Marco T." <marc@blabla.com>
Date: Fri, 27 Jan 2006 17:32:39 +0100
Links: << >>  << T >>  << A >>

"Antonio Pasini" <removethis_pasini.a@tin.it> wrote in message 
news:43da0e43$0$22090$4fafbaef@reader1.news.tin.it...
> Xilinx Multi-Channel SDRAM Memory controller has 4 XCL ports. Microblaze
>> uses 2 port.
>> Now I should develop a XCL Master interface and connect it to one of the 
>> 2 free ports.
>
> Marco,  I need to the the same thing. Let's keep in touch one each other!
> Besides... if your english is a problem... are you Italian ? I am.
>
> I'll have a MB connected to OPB, using 2 XCL ports for cache; 
> MCH_SDRAM_OPB, some UARTs, all on OPB.
> Then I need to develop two XCL "masters" to read/write high speed data 
> from the remaining two XCL channels.
>
> Can we help one each other ?
>
>
>
>

Hello Antonio,
I have opened also a webcase about this trouble.
They told me to watch mch_opb_ipif core, into cores directory.

But it seems to be still not ready for use.

Marco 



Article: 95976
Subject: Re: Multichannel Opb Memory Controller question
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Fri, 27 Jan 2006 08:35:24 -0800
Links: << >>  << T >>  << A >>
Antonio Pasini wrote:
>  Xilinx Multi-Channel SDRAM Memory controller has 4 XCL ports. Microblaze
> 
>>uses 2 port.
>>Now I should develop a XCL Master interface and connect it to one of the 2 
>>free ports.
> 
> 
> Marco,  I need to the the same thing. Let's keep in touch one each other!
> Besides... if your english is a problem... are you Italian ? I am.
> 
> I'll have a MB connected to OPB, using 2 XCL ports for cache; MCH_SDRAM_OPB, 
> some UARTs, all on OPB.
> Then I need to develop two XCL "masters" to read/write high speed data from 
> the remaining two XCL channels.
> 
> Can we help one each other ?
> 
> 
> 
> 
Unfortunately there is no document solely about the XCL bus.

But read the small section in MicroBlaze reference guide on the XCL 
signals and also look at the timing diagrams in the mch_opb_sdram 
controller.

If it's still unclear email me and I will try to answer your questions.

Göran Bilski



Article: 95977
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 27 Jan 2006 16:47:00 GMT
Links: << >>  << T >>  << A >>
"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. 



Article: 95978
Subject: Re: XilNet server data streaming problem from PPC
From: "dp" <dp@tgi-sci.com>
Date: 27 Jan 2006 09:02:06 -0800
Links: << >>  << T >>  << A >>
Johan Bernsp=E5ng wrote:
> Hi
>
> On a Virtex-II Pro I'm attempting to write a very simple TCP/IP server
> application running on the PPC. The goal is that when a client connects
> to the server it will wait until the correct command from the client
> tells it to send data, so far successful. The problem is that I want the
> server to send data streaming until the client tells it to stop, and for
> some reason the client won't send the correct ACK to any data packet but
> the first one. The acknumber is not updated correctly. I suspect that I
> am doing something wrong in my server application. I am able to send
> consecutive data packets if (and only if) every packet is acknowledged
> by manually sending a packet from the client.
>
> The server only accepts one client at the time, and the connection is
> kept alive until the client disconnects it (Yes, I have added that
> feature to the TCP state machine of the XilNet library).
>
> Does anyone have similar experience with the XilNet lib? Is it possible
> to send streaming data using it?
>
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 similar
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
------------------------------------------------------


Article: 95979
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 27 Jan 2006 18:08:24 +0100
Links: << >>  << T >>  << A >>
"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


-- 
Antti Lukats
http://www.xilant.com



Article: 95980
Subject: Re: tristate to logic conversion
From: Dominik Froehlich <dfroehli@htwm.de>
Date: Fri, 27 Jan 2006 18:16:06 +0100
Links: << >>  << T >>  << A >>
John_H wrote:
> Dominik Froehlich wrote:
>> hi,
>>
>> for some devices xilinx ise offers an option to convert internal 
>> tristate buffers to equivalent logic. however, i cannot find any 
>> information how this works in detail.
>>
>> i understand that all tristate buffers driving one signal can be 
>> replaced by a multiplexer or equivalent logic. the problem is how the 
>> selector logic is derived from the original enable signals. if 
>> multiple enables are active concurrently, is there a sort of 
>> prioritization?
>>
>> why is the conversion restricted to specific devices?
>>
>> any hint, or even conference papers, manuals, etc. are very welcome.
>>
>> thank you in advance.
>>
>> dominik
> 
> The data sheet for the tristate emulators in the earliest families that 
> got rid of tristates described the situation beautifully; I would expect 
> the synthesis to do the same but I can't guarantee 100%:
> 
> When no enables are active, result is logic 1.
> When a single enable is active, the result is the signal controlled by 
> that enable.
> When more than one enable is active, the result is logic zero if *any* 
> of the inputs are a zero, otherwise 1....  Effectively it becomes an AND 
> function of the enabled inputs.
> 
> But it's never good design practice to have tristates with multiple 
> sources; that was a good way to put a crach in the old XC4000 parts if I 
> recall those days long gone correctly.  I've done multiple enabled 
> sources myself with good results where the hardware emulation was 
> described in the datasheet so very well but wouldn't have done it 
> without that backup info.

Dear John,

thank you for this information. The background of my question is academic, 
hopefully I do not crash any devices ;-). Since there are many ways the 
conversion can be done, I was interested in the particular approach that used 
used by Xilinx. Unfortunately there is a lack of information here.

If you saying this was documented for the earliest device families to which 
family do you refer in particular? I was seeking the data-sheets to XC2000 
family but didn't find any hint :-(.

Is anybody aware of according documentation for modern Xilinx devices or even 
devices of other vendors?

Thank you and have a nice weekend.

Dominik

Article: 95981
Subject: Re: So what happened to JHDLBits?
From: Neil Steiner <neil.steiner@vt.edu>
Date: Fri, 27 Jan 2006 09:19:44 -0800
Links: << >>  << T >>  << A >>
> Is the source code available anywhere?

Phil and I have already taken this discussion offline.  If others are 
interested, I suspect that if you just want to see the code, you 
probably will not find it available.  If you are interested in actively 
contributing to the project (and you understand that JHDLBits is simply 
a bridge between JHDL and JBits, along with the potential for 
supplemental JBits-based tools), I can make inquiries on your behalf.

Please note that I do not regularly monitor this group, so if you have 
further questions for me, please contact me directly.

Neil

Article: 95982
Subject: Re: PPC Memory Management
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Fri, 27 Jan 2006 09:21:06 -0800
Links: << >>  << T >>  << A >>
Hi Shane,

I assume this is on a custom board, correct?

You will need to use the debugger to download the code to the SDRAM and 
then single-step through your code to see what is happening. Pay 
attention to the address where your code is downloaded to.

Make sure that your linker script is properly set up to run code out of 
SDRAM instead from another location.

In general it's always good to start with a design from BSB (Base System 
Builder) and adapt this to your custom board. BSB will also give you a 
choice where to run the code from.

- Peter


munch wrote:
> Hi I was wondering if I could get some help with a project I'm trying
> to get started,
> 
> I'm trying to embed some C code in the PPC core of the Virtex II pro
> board, while I can get small application deployed i.e. all data and
> instructions reside in BRAM. The other code that I'm tying to embed
> is much larger and will not all reside here so I have added extra SDRAM
> the application builds correctly and downloads to the board however
> when I do so I get no output off the UART which is set as STDIN/STDOUT.
> 
> Is there anyway to configure the memory of the board so that I will get
> some output so I can verify that it's working?
> 
> I have tried using a different terminal program to read from the serial
> port and still no joy.The Baud rate and flow control all work for the
> smaller apps.
> 
> If anybody could point me in the direction of a working example I would
> greatly appreciate it.
> 
> I'm using XPS 7.1 along with ISE 7.1
> 
> Thanks
> Shane Lynch
> 


Article: 95983
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 27 Jan 2006 17:24:11 GMT
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@openchip.org> wrote in message 
news:drdk27$3o4$02$1@news.t-online.com...
<snip>
> 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
>
>
> -- 
> Antti Lukats
> http://www.xilant.com

It almost sounds like the BDSL file expected the ARM IR jtag chain rather 
than the boundary scan chain.  That *is* where the length is specified, 
isn't it?

I'm glad you've got a workaround. 



Article: 95984
Subject: Re: Impact 8.1 problems with non xilinx device in chain
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 27 Jan 2006 18:27:55 +0100
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag 
news:%GsCf.1962$wk5.137@news02.roc.ny...
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:drdk27$3o4$02$1@news.t-online.com...
> <snip>
>> 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
>>
>>
>> -- 
>> Antti Lukats
>> http://www.xilant.com
>
> It almost sounds like the BDSL file expected the ARM IR jtag chain rather 
> than the boundary scan chain.  That *is* where the length is specified, 
> isn't it?
>
> I'm glad you've got a workaround.
>
I am using proper BSDL files in both cases to support the proper IR lenght
impact still freezes, but with the workaround its no longer a showstopper.

the thing is an small FPGA board that is going to displayed at embedded
in Nurnberg so I am a little bit under pressure as the PCBs did delay.

but a few minutes the board did boot uClinux from SD card OK

I just love how easy it is to port uClinux to new platform, just
change the UCF file and there you go :)


-- 
Antti Lukats
http://www.xilant.com




Article: 95985
Subject: Re: tristate to logic conversion
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 27 Jan 2006 17:31:03 GMT
Links: << >>  << T >>  << A >>
"Dominik Froehlich" <dfroehli@htwm.de> wrote in message 
news:43v2qpF1pph55U1@news.dfncis.de...
> Dear John,
>
> thank you for this information. The background of my question is academic, 
> hopefully I do not crash any devices ;-). Since there are many ways the 
> conversion can be done, I was interested in the particular approach that 
> used used by Xilinx. Unfortunately there is a lack of information here.
>
> If you saying this was documented for the earliest device families to 
> which family do you refer in particular? I was seeking the data-sheets to 
> XC2000 family but didn't find any hint :-(.
>
> Is anybody aware of according documentation for modern Xilinx devices or 
> even devices of other vendors?
>
> Thank you and have a nice weekend.
>
> Dominik

My Spartan-2E design used the non-tristate tristates where the data sheet 
documented the "emulated" functionality (or the detail may have been in the 
Virtex-E data sheet which fully applied to Spartan-2E).  The XC2000 family 
is ancient - a little like looking for documentation on the Notre Dame 
Cathedral.  It's out there, but it's pretty academic unless you visit the 
cathedral.

The detail information you seek is quite possibly in online help for varios 
tools since tristate emulation is a function provided by the tools.  You 
could also try synthesizing code with tristate emulation and looking at the 
results at the implementation level. 



Article: 95986
Subject: Re: This is ended - there is no excuse for the false and sometimes malicious posts
From: fpga_toys@yahoo.com
Date: 27 Jan 2006 09:37:16 -0800
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> <eom>

Posting that last known factual data is neither posting false
information,
nor is it malicious intent, nor is it slander:

Slander \Slan"der\, v. t. [imp. & p. p. Slandered; p. pr. &
   vb. n. Slandering.]
   1. To defame; to injure by maliciously uttering a false
      report; to tarnish or impair the reputation of by false
      tales maliciously told or propagated; to calumniate.
      [1913 Webster]

as you falsely claimed my sharing factual data, although out of date,
was.

Slander is your and Peters open personal attacks, including the false
claim
of slander.  If you have any proof my intent was other than to be open,
direct,
factual, and accurate, please back up your rediculous claim of slander.
I have
sent you the data to backup my quote stating that Xilinx as of Feb 2005
was
holding up the release of JHDLBits. That was, is, and always will be
factual
data. If you have cause to refute it ... take it up with the original
author, and
cease this unwarranted attack on me.

Please retract your false assertion as it clearly was ment to tarnish
or impair my reputation without any cause or reason in relation to the
JHDLBits team and Xilinx as you openly claimed.


Article: 95987
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: Larry Doolittle <ldoolitt@localhost.localdomain>
Date: 27 Jan 2006 09:40:30 -0800
Links: << >>  << T >>  << A >>
On 2006-01-27, Antti Lukats <antti@openchip.org> wrote:
> "Larry Doolittle" <ldoolitt@localhost.localdomain> schrieb im Newsbeitrag 
> news:slrndti8og.2a7.ldoolitt@localhost.localdomain...
>>
>> The conservative assumption is that the EULA we all click when
>> we install ISE is a valid document, and it has NDA-like clauses.
>> The poster has clearly read that NDA very carefully.
>> [chop]
>> In the short run, maybe the regulars will admit that XDL can not
>> currently be considered an open interface.
>
> the EULA is not NDA, and there is no sign off of an NDA required to obtain 
> acces to XDL, at least I am 100% that I have not signed any NDA with Xilinx
> or any other FPGA company.

I hear what you say, and I'd like to believe it.  Now that
we can stop talking about the JHDLBits episode, there are
two remaining concerns.

How stable is Xilinx's public support of XDL likely to be?
This question is of course unanswerable.  It looks like XDL
is important to Xilinx internally, but that doesn't speak
to their commitment to keep exporting it to their customers.

Second concern: can open source software be published that
works with XDL?  IANAL (honest), but we have to look at this
from a lawyer's perspective.  On the open source side, we
have "The Open Source Definition"
  http://www.opensource.org/docs/definition_plain.php
On the Xilinx side, we have the ISE EULA
  $XILINX/license.txt
(sorry, I can't find an up-to-date copy on-line) The key
conflict [*] is between the OSD paragraph 6:

  No Discrimination Against Fields of Endeavor

  The license must not restrict anyone from making use of the
  program in a specific field of endeavor. For example, it may
  not restrict the program from being used in a business, or
  from being used for genetic research.

and the ISE license paragraph 1:

  License.  XILINX, Inc. ("XILINX") hereby grants you a nonexclusive
  license to use the application, demonstration, and system software
  included on this disk, diskette, tape or CD ROM, and related
  documentation (the "Software") solely for your use in developing
  designs for XILINX Programmable Logic devices.  No right is granted
  hereunder to use the Software, or its products, to develop designs
  for non-XILINX devices.  You own the media on which the Software is
  recorded, but XILINX and its licensors retain title to the Software
  and to any patents, copyrights, trade secrets and other intellectual
  property rights therein.

Note the inclusion of "documentation" in the Xilinx paragraph.
So if I write XDL-handling code based on that documentation, how
can I publish my code under an OSD-compliant license, that must
permit use of that code to develop designs for an Altera chip?
Yes, I know there is no existing XDL->Altera bitstream code, so
this is not an immediate practical concern.  But any OSD license
will not preclude such use, or any other uses that do not fall
under the umbrella of "developing designs for XILINX Programmable
Logic devices for non-XILINX devices", including research on
competing chip design, or transferring an NCD file back to Verilog
so it can target an ASIC or Altera chip?

Indeed, a harsh enough reading of that ISE par.1 suggests it's not
even legal to disclose information derived from reading the XDL
documentation, since such disclosure is not "solely for your use in
developing designs for XILINX Programmable Logic devices."  Hence
my earlier (quoted) comment about NDA-like clauses.

I'm sure my analysis sounds too paranoid for most people.  Can
one of the fine Xilinx engineers on this list can reassure me
that publishing XDL-handling software is not legally limited by
paragraph 1?  One way to accomplish that is for Xilinx to post the
XDL documentation on-line.  Why isn't it already in the "Xilinx
ISE 8 Software Manuals and Help"?  Or maybe it is, and I'm just
too blind to see it?

> and you are also messing up 'creation of bitstream' and XDL - XDL files and 
> NCD files contain exactly NULL information about the actual bitstream format.
> So it doesnt matter what is the license of the use of XDL it is not sufficent
> to create bitststreams anyway.

For what it's worth, I have never mixed up the two steps,
although they are indirectly related.  If and when open
source design -> XDL software is available, I assume some
clever hacker will reverse engineer the bitstream and
publish code to make the XDL -> bitstream conversion.
That will generate a legal flap akin to deCSS, and
unfortunately will cause Xilinx to reconsider its public
XDL support.

     - Larry

[*] No, I don't think the ISE license is, or should be, OSD-compliant.
The discussion here is whether code that I write, based on the
documentation given in ISE, can be released under an OSD-compliant
license, like BSD or GPL.

Article: 95988
Subject: Re: tristate to logic conversion
From: Dominik Froehlich <dfroehli@htwm.de>
Date: Fri, 27 Jan 2006 18:46:07 +0100
Links: << >>  << T >>  << A >>
I was just taking "earliest" literally, but the cathedral is quite nice :-). 
Anyway, thanks a lot for your information.

Best regards and have nice weekend.

Dominik

John_H wrote:
> "Dominik Froehlich" <dfroehli@htwm.de> wrote in message 
> news:43v2qpF1pph55U1@news.dfncis.de...
>> Dear John,
>>
>> thank you for this information. The background of my question is academic, 
>> hopefully I do not crash any devices ;-). Since there are many ways the 
>> conversion can be done, I was interested in the particular approach that 
>> used used by Xilinx. Unfortunately there is a lack of information here.
>>
>> If you saying this was documented for the earliest device families to 
>> which family do you refer in particular? I was seeking the data-sheets to 
>> XC2000 family but didn't find any hint :-(.
>>
>> Is anybody aware of according documentation for modern Xilinx devices or 
>> even devices of other vendors?
>>
>> Thank you and have a nice weekend.
>>
>> Dominik
> 
> My Spartan-2E design used the non-tristate tristates where the data sheet 
> documented the "emulated" functionality (or the detail may have been in the 
> Virtex-E data sheet which fully applied to Spartan-2E).  The XC2000 family 
> is ancient - a little like looking for documentation on the Notre Dame 
> Cathedral.  It's out there, but it's pretty academic unless you visit the 
> cathedral.
> 
> The detail information you seek is quite possibly in online help for varios 
> tools since tristate emulation is a function provided by the tools.  You 
> could also try synthesizing code with tristate emulation and looking at the 
> results at the implementation level. 
> 
> 

Article: 95989
Subject: Re: This is ended - hardly ...
From: fpga_toys@yahoo.com
Date: 27 Jan 2006 09:49:16 -0800
Links: << >>  << T >>  << A >>
Well, Austin asserts he is forwarding this to the legal department. I
hope its to open up the EULA as requested below, so that open source
can thrive in support of Xilinx and it's customers.

>Date: Fri, 27 Jan 2006 07:48:53 -0800
>From: Austin Lesea <austin.lesea@xilinx.com>
>To: "John L. Bass" <jbass@dmsd.com>
>Subject: Re: Slander?

John,

I have referred this to our legal department.

Austin

In reply to:

>From jbass Fri Jan 27 03:43:03 2006
>To: austin.lesea@xilinx.com
>Subject: Slander?

Hi Austin,

To assert slander without the complete facts, is in itself
slander. If you want to degrade discussions between us in
the public forums, then by all means keep up the personal
attacks and open direct riddicule, which combined with
Peter's transgressions is sure to win Xilinx a LOT of
EX-customers.

Slander \Slan"der\, v. t. [imp. & p. p. Slandered; p. pr. &
   vb. n. Slandering.]
   1. To defame; to injure by maliciously uttering a false
      report; to tarnish or impair the reputation of by false
      tales maliciously told or propagated; to calumniate.
      [1913 Webster]

old, but the most current available, even if incorrect because
of your failure to correct the situation is NOT slander. Slander
is your and Peters personal attacks, combined with a presumption of
purposefully withholding information to manipulate the discussion
in a negative way.

Now, I've been very careful to avoid your personal attacks, and
to correct myself publicly when needed.  Your thin skinned and
quick to get pissy reactions are far less than professional for
someone entrusted with public relations contact.

I made some half dozen inquiries into Xilinx from Feb-Apr lobbying
to get JHDLBits released, starting with my local FAE with a direct
on the record request, to support several projects I had going.
On the record, including a non-followup from the local FAE, the
requests and lobbying were ignored. The several off the record
replies where simply not to hold my breath as it would never
happen, citing the unwillingness of Xilinx to open it's IP to
open source and the sensitivity of the bit stream tools tied
into the chip resource data bases.

Xilinx, like it or not, has a strong track record of failing to
provide information in an open and direct way, and failing to follow
up on formal requests. Your and Peter's less than helpful, except
to push sales, appearance on usenet is consistant with that.

As far as my very mild introducing the corporate leach topic,
get used to it ... I actually believe in strong corporate IP
in all forms.  Get with any of the hard core FSF group, and
I'm in comparison a poster card corporate rights advocate.
There are people in the open source community that deeply resent
any and all corporate use for profit of their work after
volunteering to develop it -- and many of them. My little jab
doesn't come close to the anger you will see vent if you
push one of their buttons. Because of that, Xilinx really
does need to work on corporate image, similar to the Sun
approach, to exploit any and all open source contributions
in the best possible light.

Xilinx does need to revisit the exact wording of it's EULA
in relation to XDL, and clear up a landmine that is waiting
when restricted XDL development is merged with GPL source.

Using JHDLBits, FpgaC, and Phil's RubyHDL projects as
examples of open source partnership is likely to develop a
lot of marketing collateral in the younger developer and
engineering community. Being hostile will certainly not.

Each of these projects when they reach maturity, will provide
Xilinx, and it's customers, with substantial resources for
new non-traditional markets.

John


Article: 95990
Subject: Virtex-4 ISERDES and ADS527X ADCs
From: Sean Durkin <smd@despammed.com>
Date: Fri, 27 Jan 2006 18:49:29 +0100
Links: << >>  << T >>  << A >>
Hi *,

I'm having a litte problem trying to understand some things regarding
the ISERDES in Virtex-4-IOs.

Here's what I want to do:

We use a lot of ADS527X-ADCs from TI. Those parts output 12bit/sample
via LVDS-DDR-links running at up to 480Mbit/s. Up to now, using Virtex-2
Pro, getting this into the FPGA is a little tricky (see xapp774). In
short, the current way is to feed the serial data into two carefully
hand-placed 6-bit-shift-registers that are clocked with 180-degrees
shifted clocks, and read those shift registers out in parallel once all
12 bits have arrived. Takes quite a bit of hand-placement, you have to
be careful which I/Os you use to connect the clocks and data, you need
DCMs to do phase-shifting, etc. Kinf of tricky, but it works.

Now we're about to switch to Virtex-4, and at first glance the ISERDES
seems like the perfect thing to make it all easier. But the more I think
about it the more problems arise.

First, since all signals coming from the ADCs are differential signals,
I need to instantiate an IBUFDS for each one. Plus I need to assign the
LVDS_25-IOSTANDARD-attribute to it, as well as the DIFFTM-attribute,
since there are usually no external termination resistors on the board
to save space.

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.

Someone here posted awhile back that they would simply feed the
_n-signal in one ISERDES, the _p in another, and have them run at clocks
shifted by 180 degrees. That way, each ISERDES would give me one
6-bit-nibble of my 12-bit data word, one the "even" bits, one the "odd"
bits of my data word. Sounds pretty easy to do.

But that would mean using the two signals from a differential pair as
two separate single-ended signals. Kinda misses the whole point of using
differential signaling in the first place...

The way I see it there are several problems with this approach:

1. If I don't use an IBUFDS for the differential input signal, I can't
turn on the differential termination, plus I can't set the I/O-standard
to LVDS_25 (the tools simply ignore those settings for single-ended
I/Os). Again, kind of takes away the advantage of using LVDS in the
first place. If I do instantiate an IBUFDS to at least get termination
and set the IO-standard, I can't access the _n and _p-signals to supply
two separate ISERDES anymore, and I can't feed the IBUFDS-output-signal
to two separate ISERDES either.

2. If I use the two signals of a differential pair as two separate
single-ended signals, what I/O standard do I assign to them? It would
have to be something that can cope with the tiny little swing of an
LVDS-signal. Looking at the datasheet, each line of a differential pair
has a worst-case V(high) = 1.265V and V(low) = 1.140V, so I'd have to
use LVCMOS_15 or something like that and pray that this works.

3. To control the ADCs (reset, powerdown, serial interface for enabling
test-modes etc.), I need an I/O-voltage of 3.3V. Normally it is not a
problem to use LVDS_25-INPUTS in a bank that otherwise uses 3.3V-I/Os,
since the differential input buffers are powered by Vccaux, which is
availabe in all banks (at least that's how it is in Virtex2 Pro).
But if I have to use e.g. LVCMOS_15 for the LVDS-inputs, I need to power
the entire bank with 1.5V. Not only would that mean I need to supply yet
ANOTHER voltage on the board (one that I wouldn't need otherwise), but
it would also mean I'd waste most of an entire bank of I/Os I could've
otherwise used to control the ADCs and do some other little things. I/Os
are precious as well as the board space I'd need for an additional
regulator.

So I'm not really comfortable with this approach...

The way I see it the only way to do it "properly" is doing it the way it
was done in xapp774, which will take some effort "porting" it to Virtex-4.

Is there some more "elegant" way to do it? I'd hate to just not use the
ISERDES, those things are way to kewl to waste... :)

Any suggestions?

cu,
Sean

Article: 95991
Subject: Re: So what happened to JHDLBits?
From: fpga_toys@yahoo.com
Date: 27 Jan 2006 10:27:40 -0800
Links: << >>  << T >>  << A >>

Neil Steiner wrote:
> > Is the source code available anywhere?
>
> Phil and I have already taken this discussion offline.  If others are
> interested, I suspect that if you just want to see the code, you
> probably will not find it available.  If you are interested in actively
> contributing to the project (and you understand that JHDLBits is simply
> a bridge between JHDL and JBits, along with the potential for
> supplemental JBits-based tools), I can make inquiries on your behalf.
>
> Please note that I do not regularly monitor this group, so if you have
> further questions for me, please contact me directly.
>
> Neil

This is probably the greatest news in a year, assuming all the
components
that Alex's papers described are made available ... especially the ADB
and
Fpga simulator projects.

The big question, is since it was layered on top of JBits, does this
mean that
JBits will now go main stream with ISE as an open source interface? If
so,
celebration time ... and many thanks to the Xilinx team :)

Have fun!
John


Article: 95992
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Brian Davis" <brimdavis@aol.com>
Date: 27 Jan 2006 10:41:50 -0800
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
> We use a lot of ADS527X-ADCs from TI. Those parts output 12bit/sample
> via LVDS-DDR-links running at up to 480Mbit/s. Up to now, using Virtex-2
> Pro, getting this into the FPGA is a little tricky (see xapp774). In
> short, the current way is to feed the serial data into two carefully
> hand-placed 6-bit-shift-registers that are clocked with 180-degrees
> shifted clocks, and read those shift registers out in parallel once all
> 12 bits have arrived. Takes quite a bit of hand-placement, you have to
> be careful which I/Os you use to connect the clocks and data, you need
> DCMs to do phase-shifting, etc. Kinf of tricky, but it works.

(posted without having looked at the ADS datasheet or V4 IO clocking)

 I've sucessfully done this sort of thing in V2-ish parts using one
of the nifty _DIFF_OUT buffers ( or hand built equivalent) to create
complementary local clocks to the DDR IOB registers (XAPP609),
with the next CLB register stage constrained only by a MAX_DELAY,
and the DCM clocks only used for the half rate logic.

  This makes it fairly easy to hit IOB DDR timing without needing
any funky DCM phase shift delay calibration logic, only LOC's on
the I/Os to the proper local clocking region.

 At 480 Mbps, I'd advise sticking with LVDS & DT terminators.

have fun,
Brian


Article: 95993
Subject: Re: C to FPGA Tools (Impulse C and others) and necessary trig IP
From: ptkwt@aracnet.com (Phil Tomson)
Date: 27 Jan 2006 18:42:03 GMT
Links: << >>  << T >>  << A >>
In article <43da132a$0$15788$14726298@news.sunsite.dk>,
Symon <symon_brewer@hotmail.com> wrote:
>"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?
>>
>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! ;-)
>
>Back in the real world, I think you're gonna have to code this in an HDL. I 
>suggest doing some research on CORDIC algorithms.
>Alternatively, For SIN/COS you might consider the Sunderland algorithm and 
>the sine-phase difference algorithm.
>For square roots, I like this:-
>http://lib.tkk.fi/Diss/2005/isbn9512275279/article3.pdf
>HTH.

Often, for sin and cos you can get by with a lookup table.  Depending on how 
much accuracy you actually need your lookup table may not even need to be all 
that large, especially since you only need from 0 to 90 degrees in the table.  


Phil

Article: 95994
Subject: HOW CAN I USE OPB EMC
From: shane <shanel2k4@yahoo.com>
Date: Fri, 27 Jan 2006 11:01:48 -0800
Links: << >>  << T >>  << A >>
hi can anyone tell me how can i use opb emc for controlling more than two memory banks. opb emc can be used for 8 memory banks each bank can have different data width. one memory bank already being used is external memory SRAM with 32 data width. but i want to add flash memory to EMC with a data width of 8. is there any tutorial of how i can add a memory bank via EMC?

it would be really great help if some one can answer this thank you in advance

Article: 95995
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 27 Jan 2006 19:05:34 -0000
Links: << >>  << T >>  << A >>

"Brian Davis" <brimdavis@aol.com> wrote in message 
news:1138387310.365316.257760@z14g2000cwz.googlegroups.com...
> Sean Durkin wrote:
>> We use a lot of ADS527X-ADCs from TI. Those parts output 12bit/sample
>> via LVDS-DDR-links running at up to 480Mbit/s. Up to now, using Virtex-2
>> Pro, getting this into the FPGA is a little tricky (see xapp774). In
>> short, the current way is to feed the serial data into two carefully
>> hand-placed 6-bit-shift-registers that are clocked with 180-degrees
>> shifted clocks, and read those shift registers out in parallel once all
>> 12 bits have arrived. Takes quite a bit of hand-placement, you have to
>> be careful which I/Os you use to connect the clocks and data, you need
>> DCMs to do phase-shifting, etc. Kinf of tricky, but it works.
>
> (posted without having looked at the ADS datasheet or V4 IO clocking)
>
> I've sucessfully done this sort of thing in V2-ish parts using one
> of the nifty _DIFF_OUT buffers ( or hand built equivalent) to create
> complementary local clocks to the DDR IOB registers (XAPP609),
> with the next CLB register stage constrained only by a MAX_DELAY,
> and the DCM clocks only used for the half rate logic.
>
>  This makes it fairly easy to hit IOB DDR timing without needing
> any funky DCM phase shift delay calibration logic, only LOC's on
> the I/Os to the proper local clocking region.
>
> At 480 Mbps, I'd advise sticking with LVDS & DT terminators.
>
> have fun,
> Brian
>
Guys,
It's Friday night and I hear the siren call of the pub, so excuse the 
briefness of this answer!

I've also had great success with DDR links without resorting to DCM phase 
shift complexity. Check out XAPP233 figs. 9 and 10. 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.
Agree totally with Brian's recommendation re. LVDS_DT.
HTH, Syms. 



Article: 95996
Subject: Re: C to FPGA Tools (Impulse C and others) and necessary trig IP
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 27 Jan 2006 19:10:30 -0000
Links: << >>  << T >>  << A >>
"Phil Tomson" <ptkwt@aracnet.com> wrote in message 
news:drdphr02ac0@enews1.newsguy.com...
> In article <43da132a$0$15788$14726298@news.sunsite.dk>,
> Symon <symon_brewer@hotmail.com> wrote:
>>Alternatively, For SIN/COS you might consider the Sunderland algorithm and
>>the sine-phase difference algorithm.
>
> Often, for sin and cos you can get by with a lookup table.  Depending on 
> how
> much accuracy you actually need your lookup table may not even need to be 
> all
> that large, especially since you only need from 0 to 90 degrees in the 
> table.
>
>
> Phil

Yep, the algorithms I mentioned dramatically reduce the size of the lookup 
table for a given accuracy.
Cheers, Syms. 



Article: 95997
Subject: Re: Are the Xilinx pcores files not searchable?
From: Duane Clark <dclark@junkmail.com>
Date: Fri, 27 Jan 2006 19:13:56 GMT
Links: << >>  << T >>  << A >>
agou wrote:
> I found where the file is by hand later. What I am curious is when I
> used the SEARCH program to look for it, I could get it. Why is that?
> 

That I have no idea about. I'm running Linux, so I don't even know what 
the "SEARCH" program is.

By the way, hopefully you noticed that the XilinxCoreLibs are a bit 
unusual. While quite a few of the files in that library are used in 
simulation, they are not used in synthesis. The synthesis tool sees the 
lines in async_fifo_v4_0_comp.vhd:

attribute GENERATOR_DEFAULT of async_fifo_v4_0: component is
	  "generatecore com.xilinx.ip.async_fifo_v4_0.async_fifo_v4_0";

and uses an EDK tool to generate the core. I find it kind of strange 
that the source files are in ISE but the generation tool is in EDK. Here 
are the lines from the log file:

Release 7.1.04i - edk_generatecore $Revision: 1.1.2.1.4.14.2.1 $
Copyright (c) 1995-2005 Xilinx, Inc.  All rights reserved.
Warning: EDIF Netlist being generated
Generated unit <fft_top_async_fifo_v4_0>.

Article: 95998
Subject: Re: Virtex-4 ISERDES and ADS527X ADCs
From: "johnp" <johnp3+nospam@probo.com>
Date: 27 Jan 2006 11:15:43 -0800
Links: << >>  << T >>  << A >>
Brian -

I don't see any documentation on the DIFF_OUT buffers you mention.

Do you have any info on them or pointers to doc?

Thanks!

John Providenza


Article: 95999
Subject: Re: HOW CAN I USE OPB EMC
From: Duane Clark <dclark@junkmail.com>
Date: Fri, 27 Jan 2006 19:37:05 GMT
Links: << >>  << T >>  << A >>
shane wrote:
> hi can anyone tell me how can i use opb emc for controlling more than
> two memory banks. opb emc can be used for 8 memory banks each bank
> can have different data width. one memory bank already being used is
> external memory SRAM with 32 data width. but i want to add flash
> memory to EMC with a data width of 8. is there any tutorial of how i
> can add a memory bank via EMC?

I would suggest that you not attempt to add it as a separate bank on an 
existing opb emc. Instead, put in a separate opb emc instance just for 
the flash. Here are settings I use for one particular flash, from the 
system.mhs file:

# TE28F640-J3, flash mem
BEGIN opb_emc
  PARAMETER INSTANCE = my_flash
  PARAMETER HW_VER = 2.00.a
  PARAMETER C_NUM_BANKS_MEM = 1
  PARAMETER C_OPB_CLK_PERIOD_PS = 10000
  PARAMETER C_MEM0_BASEADDR = 0x94000000
  PARAMETER C_MEM0_HIGHADDR = 0x94FFFFFF
  PARAMETER C_MEM0_WIDTH = 32
  PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 0
  PARAMETER C_TCEDV_PS_MEM_0 = 120000
  PARAMETER C_TAVDV_PS_MEM_0 = 120000
  PARAMETER C_THZCE_PS_MEM_0 = 35000
  PARAMETER C_THZOE_PS_MEM_0 = 15000
  PARAMETER C_TWC_PS_MEM_0 = 120000
  PARAMETER C_TWP_PS_MEM_0 = 70000
  BUS_INTERFACE SOPB = opb_bus
  PORT Mem_A = flash_a
  PORT Mem_DQ = flash_dq
  PORT Mem_CEN = flash_cs_l
  PORT Mem_OEN = flash_oe_l
  PORT Mem_WEN = flash_we_l
  PORT Mem_RPN = flash_rst_l
END



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