Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
"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. MarcoArticle: 95976
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 BilskiArticle: 95977
"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
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
"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.comArticle: 95980
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. DominikArticle: 95981
> 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. NeilArticle: 95982
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
"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
"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.comArticle: 95985
"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
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
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: 95988I 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
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: 95990Hi *, 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, SeanArticle: 95991
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! JohnArticle: 95992
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, BrianArticle: 95993
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. PhilArticle: 95994
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 advanceArticle: 95995
"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
"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
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
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 ProvidenzaArticle: 95999
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:
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