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
Let me clarify this question a little bit. I didn't mean for it to be offensive. What I'm wondering is if FPGA producers mind doing support through this medium, and if they feel it's effective. I recognize most support issues go through specific support channels. Is the forum, though, a primary support channel? Is this a method to actually get at the engineers? For example, my questions about the Xilinx mapper would be easily answered by an engineer who works on the project, yet I doubt few others in the world actually know the answers, including Xilinx tech support -- they would have to get it from the engineers. So what is the correct route for that information? 100% of my posts to the Xilinx Forum have gone unanswered. About 70% of my posts to this forum have gone unanswered, though I would say 70% at least get commented on in this forum. I recognize some of that may be my fault, i.e., the question is too stupid or too hard or too specific or not enough info, etc. "Brannon King" <bking@starbridgesystems.com> wrote in message news:bu6qgu$4ro@dispatch.concentric.net... > Just curious: Do any Altera/Xilinx engineers actually read this forum? And > actually post answers? Prefer the forums on your websites? Prefer tech > support emails? > >Article: 64876
Hello, > Do any Altera/Xilinx engineers actually read this forum? Yes, a fair number of engineers read this forum, including myself... It is very interesting to see what kinds of questions people need answered. > And actually post answers? Fewer. I post occasionally when I feel I can offer some useful information. > Prefer the forums on your websites? Prefer tech > support emails? My personal opinion follows. If you have an issue with a Xilinx product (silicon, software, ipcore...) the first place I would go is to the Xilinx Support team. They exist to help you. Your case is logged, and if it needs to get escalated to the development engineers, it will be. EricArticle: 64877
Hi, > Results: > Max host write speed: 70MB/s > Max host read speed: 230MB/s > > The timer does not include the memory allocations. > Any ideas why the write speed is so much slower? > Would it be the latency parameters in the core? An > OS issue? When you say "write speed" do you refer to your device becoming bus master and doing memory writes to the system RAM behind the host bridge? Likewise, by the term "read speed" do you refer to your device becoming bus master and doing memory reads of the system RAM behind the host bridge? I just want to make sure I didn't mis-interpret your question before I try to answer it. Or did I get it backwards? EricArticle: 64878
To clarify one issue, host write refers to DMA busmaster read (the busmaster is on my device and is actually reading the data in from the host.) "Brannon King" <bking@starbridgesystems.com> wrote in message news:bu6q76$4s4@dispatch.concentric.net... > Params: > Xilinx's PCIX core for PCI64/PCIX at 66MHz > 2v4000-4 running the controller core with 40 Fifos (10 targets, 2 channels, > r/w) and a busmaster wrapper > Tyan 2721 MB w/Xeon 2.6GHz w/ 4GB RAM > Win2k Server sp4 > No scatter/gather support in driver > Exact same software and hardware for both reads and writes > Bus commands 1110 and 1111 > > Results: > Max host write speed: 70MB/s > Max host read speed: 230MB/s > Development time: six months w/ two engineers for both driver and core > wrapper > > > The timer does not include the memory allocations. Any ideas why the write > speed is so much slower? Would it be the latency parameters in the core? An > OS issue? > >Article: 64879
Is the bus operating in PCI or PCIX mode? If it's in PCI mode then you are
seeing the disadvantage of not being able to post read requests. Your device is
getting told to retry while the chipset fetches the read data.
If it's in PCIX mode then you should make sure that your DMA engine is issuing
as many posted read requests as possible of as large a size as possible.
Mark
Brannon King wrote:
> To clarify one issue, host write refers to DMA busmaster read (the busmaster
> is on my device and is actually reading the data in from the host.)
>
> "Brannon King" <bking@starbridgesystems.com> wrote in message
> news:bu6q76$4s4@dispatch.concentric.net...
>
>>Params:
>>Xilinx's PCIX core for PCI64/PCIX at 66MHz
>>2v4000-4 running the controller core with 40 Fifos (10 targets, 2
>
> channels,
>
>>r/w) and a busmaster wrapper
>>Tyan 2721 MB w/Xeon 2.6GHz w/ 4GB RAM
>>Win2k Server sp4
>>No scatter/gather support in driver
>>Exact same software and hardware for both reads and writes
>>Bus commands 1110 and 1111
>>
>>Results:
>>Max host write speed: 70MB/s
>>Max host read speed: 230MB/s
>>Development time: six months w/ two engineers for both driver and core
>>wrapper
>>
>>
>>The timer does not include the memory allocations. Any ideas why the write
>>speed is so much slower? Would it be the latency parameters in the core?
>
> An
>
>>OS issue?
>>
>>
>
>
>
Article: 64880
Hello! I'm trying to interface a Spartan-IIE to one of analog device's
new ADSP-21262 DSPs. The problem is that my application requires
high-bandwidth communication with the DSP, and the DSP's parallel
interface expects an _asynchronous_ ram. That's right, it has
edge-triggering ALE, RE, and WE lines that are expected to interface
to standard static SRAM.
I have been trying to come up with a solution to talking to the FPGA,
to no avail. The ALE signal is asserted for only 10 ns, thus
oversampling the pins is going to be really difficult (and that's
ignoring all the potential metastability issues!) Has anyone ever made
an interface like this work? I know on the spartan-series, internal
flip-flops can only be gated by the internal clock nets, which can
only be sourced by one of the 4 clock pins.
Any help would be appreciated!
Thanks,
Steve
Article: 64881charlesg77@yahoo.com (chuk) wrote in message news:<faa526d6.0401150231.2eae1819@posting.google.com>... > Generating clock delays > > I am relatively new to VHDL so pleas excuse me if this is too easy a > question. I need to be able to generate a time shifted version of the > clk signal for control purposes in an Xilinx based project. There are > several options that I have come across: > > -Using the after ??n, but this dose not seem to generate any > difference Go re-read the synthesis tool documentation, especially the part about which VHDL language features are supported and which ones aren't. "after" isn't. Spend a moment or two thinking about WHY. Hint: Think Hardware. > -using the wait until statement though this is not supported by Xilinx > for some reason See above. > -using the dll (is this the most efficient manor?) That's one way of doing it. > I would like someone to tell me which is the best and most > controllable manor of generating a clock delay. Thanks Perhaps rather than delaying the clock in such a manner, you need a higher-frequency master clock that you can use to clock your whole design. A simple state machine or whatever can be used to create clock enables at the appropriate time. -aArticle: 64882
The Cyclone device is programmable using only the proprietary mechanism. It does not support 1149.1 or 1532 based programming. Rene Tschaggelar wrote: > The Altera Cyclone Programming device EPCS1 are shown > to be programmed in the AS mode requiring an own connector. > Since the JTAG was never officially declared outdated, > I'd expect a way to program the cyclone plus the EPCS1 in JTAG > mode. I wasn't able to find it yet though. > > ReneArticle: 64883
Open a webcase. That's the "right" approach, but not necessarily the fastest path to an answer. This also enables an escalation mechanism that would take the question to the appropriate group/individuals if the first line can't handle it. I don't work for Xilinx, so this description might not be entirely accurate. That's what it looks like as a user. I've given up posting on the forums in the Xilinx site. I don't know what you have to do to get a question answered there. Besides, for the right questions, this newsgroup provides significantly more resources than that approach. In general terms, I'll do a Google search of this NG before I attempt to find anything in the Xilinx website. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Brannon King" <bking@starbridgesystems.com> wrote in message news:bu6tqr$4rp@dispatch.concentric.net... > Let me clarify this question a little bit. I didn't mean for it to be > offensive. What I'm wondering is if FPGA producers mind doing support > through this medium, and if they feel it's effective. I recognize most > support issues go through specific support channels. Is the forum, though, a > primary support channel? Is this a method to actually get at the engineers? > For example, my questions about the Xilinx mapper would be easily answered > by an engineer who works on the project, yet I doubt few others in the world > actually know the answers, including Xilinx tech support -- they would have > to get it from the engineers. So what is the correct route for that > information? 100% of my posts to the Xilinx Forum have gone unanswered. > About 70% of my posts to this forum have gone unanswered, though I would say > 70% at least get commented on in this forum. I recognize some of that may be > my fault, i.e., the question is too stupid or too hard or too specific or > not enough info, etc. > > > "Brannon King" <bking@starbridgesystems.com> wrote in message > news:bu6qgu$4ro@dispatch.concentric.net... > > Just curious: Do any Altera/Xilinx engineers actually read this forum? And > > actually post answers? Prefer the forums on your websites? Prefer tech > > support emails? > > > > > >Article: 64884
Eric,
> From a simulation point of view, this will work. However, you
> will find a problem in the implementation. If you insert any
> logic after the IBUF for IDSEL in the wrapper file, you will
> prevent the IFD packing into the IOB. What you'll see when you
> run PAR is that you won't be able to meet the input setup specs
> for IDSEL.
My IDSEL setup time grew to 1.9ns; which would probably be fine because of
address stepping but would still be a non-compliance.
> I haven't tried this, but I think a workable solution for your
> case would be to gate the LCK signal in the wrapper file. This
> would, I believe, hold the core and the user logic (but not the
> bus mode detection logic) in reset. I appologize for offering
> a solution that I haven't tested, and I hope it won't take more
> than a few minutes of your time to try out... If it doesn't
> work, contact me privately and we can look at other options.
Works. Sweet. We're looking at adding a second PROM in the clean-up spin, but if
our target server BIOS's are tolerant of the bus population changing when the
mode switches it might not be necessary.
I haven't actually tried the fix in the box yet but the Intel server/BIOS that
we are testing with seems to enumerate the bus periodically. I suspect it is the
hot-plug controller in the chipset. Hopefully it will accept the card magically
appearing following the mode switch.
> You do need to set the mode forcing bits in the cfg file. Let me
> describe what I did to see the operation of RTR. I'm using the
... snip....
> tests. It then resets the bus again, in 64-bit PCI-X during
> RST# assertion. After this completes, you will see that RTR is
> deasserted, as expected.
>
I managed to get RTR working after playing around with my testbench reset
timing. I actually see RTR working as I would expect regardless of whether or
not I force the mode bit.
Thanks!
Mark
Article: 64885guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0401150123.31c7af38@posting.google.com>... > Hello all, > > I have a FSM with 6 states: IDLE, and S0-S5. Transitions are > synchronized with the system clock, but next state might be determined > by signals which are asynchronous to that clock. Those asynchronous signals should be synchronized to the clock, lest you get into troubles! -aArticle: 64886
It's a single data path. It looks like none of the current FPGA's will support this in non-trivial application. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Robert Sefton" <rsefton@abc.net> wrote in message news:bu53b6$dpfal$1@ID-212988.news.uni-berlin.de... > "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message > news:r2nNb.1094$746.125@newssvr29.news.prodigy.com... > > RLDRAM II can (will) hit 400MHz (2.5ns cycle) actual clock rate. Of > course, > > still DDR, so 800Mb/s/pin peak. > > > > Martin - > > Virtex-II (and Pro) should be able to handle that. Xilinx's SPI-4.2 and > HyperTransport cores run up to 400MHz DDR (800Mbps per pin). I assume > RLDRAM has separate (uni-directional) read and write paths? I can't > imagine anything running bi-directional at those rates. > > Robert > >Article: 64887
Hello, Brannon King wrote: > "Host write" refers to busmaster read. > Max host write speed: 70MB/s > Max host read speed: 230MB/s I think Mark described it well in his post. If this is PCI mode, it isn't entirely surprising. If this is in PCI-X mode, and you are using split transactions (supporting multiple outstanding is best) then you may need to do some hunting. The best tool for this is a bus analyzer, if you have one (or maybe can borrow one from a vendor to "evaluate" it?) There could be all manner of secondary issues that cause problems: * bus traffic from other agents * you are behind a bridge * your byte counts are small Sorry I don't have a more specific answer for you. EricArticle: 64888
Brannon King wrote: > Let me clarify this question a little bit. I didn't mean for it to be > offensive. What I'm wondering is if FPGA producers mind doing support > through this medium, and if they feel it's effective. I recognize most > support issues go through specific support channels. Is the forum, though, a > primary support channel? Is this a method to actually get at the engineers? > For example, my questions about the Xilinx mapper would be easily answered > by an engineer who works on the project, yet I doubt few others in the world > actually know the answers, including Xilinx tech support -- they would have > to get it from the engineers. So what is the correct route for that > information? 100% of my posts to the Xilinx Forum have gone unanswered. > About 70% of my posts to this forum have gone unanswered, though I would say > 70% at least get commented on in this forum. I recognize some of that may be > my fault, i.e., the question is too stupid or too hard or too specific or > not enough info, etc. On the few occasions when I've had a problem, I've opened a Webcase and had a reply in a day or so. Leon -- Leon Heller, G1HSM Email: aqzf13@dsl.pipex.com My low-cost Philips LPC210x ARM development system: http://www.geocities.com/leon_heller/lpc2104.htmlArticle: 64889
Brannon, The programmer working on the fiendishly difficult mapper code is unlikely to read this newsgroup. Further, the question you are asking today is three year old code to them. Bottom line: ask the hotline. If the tech support folks don't know, they know where to go ask. One reason why Peter and I look so intelligent (other than we really are intelligent!) is that we have hundreds of even smarter people working right near us..... Austin Brannon King wrote: > Let me clarify this question a little bit. I didn't mean for it to be > offensive. What I'm wondering is if FPGA producers mind doing support > through this medium, and if they feel it's effective. I recognize most > support issues go through specific support channels. Is the forum, though, a > primary support channel? Is this a method to actually get at the engineers? > For example, my questions about the Xilinx mapper would be easily answered > by an engineer who works on the project, yet I doubt few others in the world > actually know the answers, including Xilinx tech support -- they would have > to get it from the engineers. So what is the correct route for that > information? 100% of my posts to the Xilinx Forum have gone unanswered. > About 70% of my posts to this forum have gone unanswered, though I would say > 70% at least get commented on in this forum. I recognize some of that may be > my fault, i.e., the question is too stupid or too hard or too specific or > not enough info, etc. > > > "Brannon King" <bking@starbridgesystems.com> wrote in message > news:bu6qgu$4ro@dispatch.concentric.net... > >>Just curious: Do any Altera/Xilinx engineers actually read this forum? And >>actually post answers? Prefer the forums on your websites? Prefer tech >>support emails? >> >> > > >Article: 64890
Brannon King wrote:
> VHDL/Verilog compilers perform an optimization that I think should be done
> in the mapper. I think it is part of the "slice packing." Maybe someone can
> explain why this is done in this fashion. What I want is to use my 3rd-party
> structural EDIF, and currently I'm having to perform this optimization
> manually.
Consider getting the source code.
A netlist is much more difficult
to work with.
-- Mike Treseler
Article: 64891My guess would be it's an ECS (schematic editor) bug. I'd say 90% of the bugs I've found are with ECS. One that I found in 6.1i was that if you put the attribute "uselowskewlines" onto a net, synthesis chokes because the vhf output file misspells the key word "SIGNAL" as "SIGANL". Another way to create a constant that I use is to create a VHDL module with an output port that I assign the constant to. I haven't tried this in 6.1i yet though. Bob wrote: > I need help in creating constants to be used with schematic capture. > > In previous versions of Xilinx ISE I used to create schematic symbols > for constants (i.e. 0xA5) by creating a schmetic with 8 buffers. The > inputs were connected to gnd or vcc to create the constant. The > outputs of the buffer were connected to a bus CONST(7:0). > > Then I could use this constant anywhere in my schematic by inserting > this part. > > I tried this on the latest ISE 6.1 and got the following error when I > compiled. > > ERROR:Xst:1539 - C:/Projects/DemoTop.vhf line 122: Formal port in > component <const8_80> must be an identifier. > > Here is the DemoTop.vhf output: > > XLXI_30 : const8_80 > port map (Const(7 downto 0)=>XLXN_12(7 downto 0)); > > Why doesn't this work anymore? Is there a better way to create a > constant. I know that Altera has a constant macro. Is there any easy > way in Xilinx. > > Thanks, > > Bob > > P.S. Please post the answer in the newsgroup rather than emailing it.Article: 64892
For those speed tests the device was in PCI mode. I was assuming it would be the same speed as PCIX (at the same bus speed) because the timing diagrams all looked compatible between the two. Please explain what you mean by "post read requests". Is there some workaround for this to make the PCI mode handle this better? "Mark Schellhorn" <mark@seawaynetworks.com> wrote in message news:JlDNb.1075$XZ.151148@news20.bellglobal.com... > Is the bus operating in PCI or PCIX mode? If it's in PCI mode then you are > seeing the disadvantage of not being able to post read requests. Your device is > getting told to retry while the chipset fetches the read data. > > If it's in PCIX mode then you should make sure that your DMA engine is issuing > as many posted read requests as possible of as large a size as possible. > > Mark > > > Brannon King wrote: > > To clarify one issue, host write refers to DMA busmaster read (the busmaster > > is on my device and is actually reading the data in from the host.) > > > > "Brannon King" <bking@starbridgesystems.com> wrote in message > > news:bu6q76$4s4@dispatch.concentric.net... > > > >>Params: > >>Xilinx's PCIX core for PCI64/PCIX at 66MHz > >>2v4000-4 running the controller core with 40 Fifos (10 targets, 2 > > > > channels, > > > >>r/w) and a busmaster wrapper > >>Tyan 2721 MB w/Xeon 2.6GHz w/ 4GB RAM > >>Win2k Server sp4 > >>No scatter/gather support in driver > >>Exact same software and hardware for both reads and writes > >>Bus commands 1110 and 1111 > >> > >>Results: > >>Max host write speed: 70MB/s > >>Max host read speed: 230MB/s > >>Development time: six months w/ two engineers for both driver and core > >>wrapper > >> > >> > >>The timer does not include the memory allocations. Any ideas why the write > >>speed is so much slower? Would it be the latency parameters in the core? > > > > An > > > >>OS issue? > >> > >> > > > > > > >Article: 64893
Clarification: ModelSim XE Starter is free and supports 500 lines of code. ModelSim XE is a $945 option and supports 40,000 lines of code. Steve ram wrote: >Hi Edward. > ModelSIm XE supports only 500 lines of code, so you need to get >ModelSim SE/PE to run MicroBlaze simulation. >bye >Ram > >Article: 64894
Hi Tim.....;-) > > >Perhaps I can shed a bit of light on the Altera piece of this story. I >think our press release states things pretty clearly, but evidently has >been misinterpreted a bit. > >Altera won a design with Cyclone and NIOS in a module that allows a >variety of different instruments to connect into Gibson's innovative >MaGIC digital music technology. In doing so, Cyclone replaced a >competitive FPGA and a small processor. This is not in the guitar but in >the technology that enables Gibson to reach a much broader audience with >MaGIC. Hence the headline that we are helping Gibson to Spread MaGIC. > >It appears as though since the name of the company is Gibson Guitar, >many people automatically assumed the release was about the actual >guitar without reading the details. > >As for why Gibson chose Altera, as I understand it there were both >technical and business reasons behind their decision. The combination of >NIOS and Cyclone fit the application well. I also believe that Gibson >sees the benefits of a two vendor model. > >On the guitar side of things, I don't have any reason to doubt that >Gibson intends to use Xilinx in production for the Guitar. While I could >speculate further, it would be innappropriate and unprofessional. > >Hopefully that sheds some light on what Altera announced. Any confusion >on the topic was purely unintentional. > >Tim Colleran >Altera Corporation Brian Dipert Technical Editor: Mass Storage, Memory, Multimedia, PC Core Logic and Peripherals, and Programmable Logic EDN Magazine: http://www.edn.com 5000 V Street Sacramento, CA 95817 (916) 454-5242 (voice), (617) 558-4470 (fax) ***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY*** mailto:bdipert@NOSPAM.edn.com Visit me at http://www.bdipert.comArticle: 64896
On 15 Jan 2004 13:11:49 -0800, stevetshannon@yahoo.com (Steve T Shannon) wrote: >Hello! I'm trying to interface a Spartan-IIE to one of analog device's >new ADSP-21262 DSPs. The problem is that my application requires >high-bandwidth communication with the DSP, and the DSP's parallel >interface expects an _asynchronous_ ram. That's right, it has >edge-triggering ALE, RE, and WE lines that are expected to interface >to standard static SRAM. > >I have been trying to come up with a solution to talking to the FPGA, >to no avail. The ALE signal is asserted for only 10 ns, thus >oversampling the pins is going to be really difficult (and that's >ignoring all the potential metastability issues!) Has anyone ever made >an interface like this work? I know on the spartan-series, internal >flip-flops can only be gated by the internal clock nets, which can >only be sourced by one of the 4 clock pins. ALE, RE, etc. are actually timed from a clock inside the DSP. Can you access the processor core clock? If so, you can pass that to the FPGA and have a fully synchronous interface, assuming your FPGA can handle the speed (200MHz). Ummm, I can't see a CCLK out pin on the datasheet, but you do control CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK). You might be able to do something with that (like using an external PLL to form your own CCLK). It might be simpler to treat the signals as asynchronous. Can Spartan-IIE do DDR? If so, you only need a clock a little over 50MHz to sample the 10ns ALE strobe. Regards, Allan.Article: 64897
"Brannon King" <bking@starbridgesystems.com> wrote in message news:<bu6q76$4s4@dispatch.concentric.net>... > Params: > Xilinx's PCIX core for PCI64/PCIX at 66MHz > 2v4000-4 running the controller core with 40 Fifos (10 targets, 2 channels, > r/w) and a busmaster wrapper > Tyan 2721 MB w/Xeon 2.6GHz w/ 4GB RAM > Win2k Server sp4 > No scatter/gather support in driver > Exact same software and hardware for both reads and writes > Bus commands 1110 and 1111 > > Results: > Max host write speed: 70MB/s > Max host read speed: 230MB/s > Development time: six months w/ two engineers for both driver and core > wrapper > > > The timer does not include the memory allocations. Any ideas why the write > speed is so much slower? Would it be the latency parameters in the core? An > OS issue? Have you used a PCI bus analyzer to see the bus traffic? Is the write data sourced from cache, or is it being fetched from main memory? --aArticle: 64898
> Just curious: Do any Altera/Xilinx engineers actually read this forum? And > actually post answers? Prefer the forums on your websites? Prefer tech > support emails? Not much more to say than has been said -- various Altera employees monitor this newsgroup, and we try to post responses when we know the answers and have the time. But Altera tech support (hot line, mysupport.altera.com) are the preferred ways for you to get support. Not only do you get escalation, tracking, etc., but there's also a better chance your question will be answered, and answered correctly. Tech support has access to a database of problems and resolutions, and chances are you're not the first to ask your particular question. Regards, Paul Leventis Altera Corp.Article: 64899
"Brannon King" <bking@starbridgesystems.com> wrote in message news:<bu6qgu$4ro@dispatch.concentric.net>... > Just curious: Do any Altera/Xilinx engineers actually read this forum? And > actually post answers? Prefer the forums on your websites? Prefer tech > support emails? I, as well as many other Altera folks read this news group. While I can't speak for my colleagues on comp.arch.fpga specifically, I read/answer questions relevant to my area of expertise, but only if I have time. This isn't one of my official duties per se, but I am interested in seeing people succeed in using our products, that's all. Jesse Kempa Altera Corp.
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