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 64875

Article: 64875
Subject: Re: yo, Mr. FPGA Engineer
From: "Brannon King" <bking@starbridgesystems.com>
Date: 15 Jan 2004 15:39:55 EST
Links: << >>  << T >>  << A >>
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
Subject: Re: yo, Mr. FPGA Engineer
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 15 Jan 2004 12:52:32 -0800
Links: << >>  << T >>  << A >>

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.

Eric

Article: 64877
Subject: Re: DMA w/ Xilinx PCIX core: speed results and question
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 15 Jan 2004 12:58:53 -0800
Links: << >>  << T >>  << A >>

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?

Eric

Article: 64878
Subject: Re: DMA w/ Xilinx PCIX core: speed results and question
From: "Brannon King" <bking@starbridgesystems.com>
Date: 15 Jan 2004 16:01:44 EST
Links: << >>  << T >>  << A >>
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
Subject: Re: DMA w/ Xilinx PCIX core: speed results and question
From: Mark Schellhorn <mark@seawaynetworks.com>
Date: Thu, 15 Jan 2004 16:11:06 -0500
Links: << >>  << T >>  << A >>
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
Subject: Spartan-IIE as an ASYNC RAM?
From: stevetshannon@yahoo.com (Steve T Shannon)
Date: 15 Jan 2004 13:11:49 -0800
Links: << >>  << T >>  << A >>
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: 64881
Subject: Re: Generating clock delays
From: Bassman59a@yahoo.com (Andy Peters)
Date: 15 Jan 2004 13:13:14 -0800
Links: << >>  << T >>  << A >>
charlesg77@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.

-a

Article: 64882
Subject: Re: Altera Cyclone Programming device programming
From: Neil Glenn Jacobson <neil.jacobson@xilinx.com>
Date: Thu, 15 Jan 2004 13:15:07 -0800
Links: << >>  << T >>  << A >>
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.
>
> Rene



Article: 64883
Subject: Re: yo, Mr. FPGA Engineer
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 15 Jan 2004 21:27:58 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: logicore PCIX issue/question
From: Mark Schellhorn <mark@seawaynetworks.com>
Date: Thu, 15 Jan 2004 16:31:51 -0500
Links: << >>  << T >>  << A >>
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: 64885
Subject: Re: Gray encoding for FSM
From: Bassman59a@yahoo.com (Andy Peters)
Date: 15 Jan 2004 13:43:30 -0800
Links: << >>  << T >>  << A >>
guillerodriguez@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!

-a

Article: 64886
Subject: Re: Faster than a speeding bullet...
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 15 Jan 2004 21:44:41 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: DMA w/ Xilinx PCIX core: speed results and question
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 15 Jan 2004 13:56:42 -0800
Links: << >>  << T >>  << A >>

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.
Eric

Article: 64888
Subject: Re: yo, Mr. FPGA Engineer
From: Leon Heller <aqzf13@dsl.pipex.com>
Date: Thu, 15 Jan 2004 22:35:27 +0000
Links: << >>  << T >>  << A >>


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.html


Article: 64889
Subject: Re: yo, Mr. FPGA Engineer
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 15 Jan 2004 15:14:40 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: mapper optimization
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 15 Jan 2004 15:26:18 -0800
Links: << >>  << T >>  << A >>
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: 64891
Subject: Re: Please help with Xilinx ISE Schematic question
From: Marc Guardiani <marc@guardiani.com>
Date: Thu, 15 Jan 2004 23:26:50 GMT
Links: << >>  << T >>  << A >>
My 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
Subject: Re: DMA w/ Xilinx PCIX core: speed results and question
From: "Brannon King" <bking@starbridgesystems.com>
Date: 15 Jan 2004 18:29:24 EST
Links: << >>  << T >>  << A >>
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
Subject: Re: Microblaze simulation
From: Steve Lass <lass@xilinx.com>
Date: Thu, 15 Jan 2004 16:51:04 -0700
Links: << >>  << T >>  << A >>
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
(removed)


Article: 64895
Subject: Re: clarity on Gibson Guitar Story(ies)
From: Brian Dipert <bdipert@NOSPAM.pacbell.net>
Date: Fri, 16 Jan 2004 00:08:51 GMT
Links: << >>  << T >>  << A >>
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.com

Article: 64896
Subject: Re: Spartan-IIE as an ASYNC RAM?
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Fri, 16 Jan 2004 11:38:07 +1100
Links: << >>  << T >>  << A >>
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
Subject: Re: DMA w/ Xilinx PCIX core: speed results and question
From: Bassman59a@yahoo.com (Andy Peters)
Date: 15 Jan 2004 16:46:01 -0800
Links: << >>  << T >>  << A >>
"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?

--a

Article: 64898
Subject: Re: yo, Mr. FPGA Engineer
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Fri, 16 Jan 2004 01:47:11 GMT
Links: << >>  << T >>  << A >>
> 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
Subject: Re: yo, Mr. FPGA Engineer
From: kempaj@yahoo.com (Jesse Kempa)
Date: 15 Jan 2004 18:28:30 -0800
Links: << >>  << T >>  << A >>
"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:
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