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 144525

Article: 144525
Subject: Re: Data2MEM - finding the blockrams after PAR?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 13 Dec 2009 12:10:01 +0000
Links: << >>  << T >>  << A >>
On Sat, 12 Dec 2009 23:23:22 -0800 (PST), Eric Smith <spacewar@gmail.com> wrote:
On Sat, 12 Dec 2009 23:23:22 -0800 (PST), in comp.arch.fpga you wrote:

>> The data2mem tool doesn't require you to know the physical location of
>> a particular BlockRAM, it just needs to know what the name is like a
>> UCF file does.http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2...
>
>Thanks!  I'm still confused since that manual says (page 28) "The BMM
>file <i>must</i> have LOC or PLACED constraints for each block RAM.
>These constraints can be added manually, but they are most often
>obtained as an annotated BMM file from Bitgen.  For information, see
>Using Integrated ISE(R) Design Suite Implementation Tools."  

The information you need is not where you need it, but probably exists somewhere
else.

Dim and distant memory leads me to:

Webcase 720619 may be relevant (though it was from the ISE7.1 and 9.1 days)
https://xapps2.xilinx.com/eSupport/eSupportJSP/CaseShow.jsp?id_number=720619
If you can't see it without too many registration steps, I'll post some excerpts
from it here.

Two quotes from it: 
-----------------------------------------------------------------------------------------------------------------------------
Problem 1: XILINX TOOL DEFECT
When NGDbuild fails to process a BMM file, it does not issue a Warning or an
Error as it should; just a note in the .bld log file. This makes finding
problems harder. (May have been fixed since 7.1; I haven't checked with Webpack
9.2)
-----------------------------------------------------------------------------------------------------------------------------
What DID help were AR#23179 and AR#24296 which explained how the "magic"
worked.

Remember: The problem manifested as PAR failing to generate a _bd.bmm
file from a flow which previously worked. Yet none of the documentation
(prior to the above AR#s) explained how it did this, to help pinpoint
the problem.

So it was unclear what communicated the BMM filename or the need to
annotate into PAR; therefore where to look to solve the problem.

I had to find the above AR#s to understand that the BMM filename is
buried in the .ncd file as a result of NGDbuild parsing it correctly;
since it was missing in the XDL file, that pointed back to NGDbuild
(where I found the failure as an obscure note in the BLD file).
-----------------------------------------------------------------------------------------------------------------------------

So 
http://www.xilinx.com/support/answers/23179.htm
and
http://www.xilinx.com/support/answers/24269.htm
may be helpful.

There was a Change Request (CR #457644) to address issues with the
documentation; I don't know what happens to CRs but the documentation may still
be incomplete. If you find this to be so, it is worth pursuing further with
Xilinx Support.

But essentially, you need to supply a BMM file (xxx.bmm) with BRAM names (and no
LOC constraints) to ... actually "Translate" aka NGDbuild - AND CHECK THE BUILD
REPORT .bld to see it was handled correctly...

(This .bmm file is usually generated by EDK, but you can hand-edit it, e.g. to
alter hierarchical names if you use an EDK generated design as a component in a
larger design)

Then the .bmm information disappears into the tool flow, only to re-emerge at
Bitgen, (I believe, though I said PAR in my quote above) which takes the same
BMM file and annotates it with placement, saving as xxx_bd.bmm. 

Hope this helps.

- Brian

Article: 144526
Subject: Re: Does a 1-bit mux glitch if only one input is known to change
From: Symon <symon_brewer@hotmail.com>
Date: Sun, 13 Dec 2009 14:10:35 +0000
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke
> <alfke@sbcglobal.net> wrote:
> 
>> In short:
>> changing a SINGLE lut input will NEVER generate a glitch.
> 
> Nice to know, and - thinking about the likely structures
> for the guts of a LUT - perfectly reasonable.  Thanks.
> 
> However.... can all other manufacturers of LUT-based 
> FPGAs make the same promise?  Again, *probably* yes; 
> but would you bet your life/reputation/fortune on it?

Hi Jonathan,
Think about it this way. If you deliberately wanted to make the output 
of a 2^N to 1 mux glitch if only one select input changes, how would you 
do it?
Cheers, Syms.

Article: 144527
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 13 Dec 2009 09:42:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 13, 6:10=A0am, Symon <symon_bre...@hotmail.com> wrote:
> Jonathan Bromley wrote:
> > On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke
> > <al...@sbcglobal.net> wrote:
>
> >> In short:
> >> changing a SINGLE lut input will NEVER generate a glitch.
>
> > Nice to know, and - thinking about the likely structures
> > for the guts of a LUT - perfectly reasonable. =A0Thanks.
>
> > However.... can all other manufacturers of LUT-based
> > FPGAs make the same promise? =A0Again, *probably* yes;
> > but would you bet your life/reputation/fortune on it?
>
> Hi Jonathan,
> Think about it this way. If you deliberately wanted to make the output
> of a 2^N to 1 mux glitch if only one select input changes, how would you
> do it?
> Cheers, Syms.

It can be done:
Suppose both data inputs are High, while you change the select input
from High to Low.
Suppose the deselect path is faster than the select path, then you
will see a Low glitch on the output.
The OP's concern is legitimate, but I had investigated and found out
and documented several times:
A mux implemented in a single Xilinx LUT does not have this problem,
since it uses pass transistors, and the internal capacitance "bridges"
the change-over.

I would assume that the other big FPGA company does it the same way.
They are just not as forthcoming with helpful information.
Peter Alfke

Article: 144528
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Dec 2009 18:13:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
Symon <symon_brewer@hotmail.com> wrote:

> Think about it this way. If you deliberately wanted to make 
> the output of a 2^N to 1 mux glitch if only one select input 
> changes, how would you do it?

If the transistors selecting one input turn off before the ones
selecting the second input (of a 2 to 1) turn on then the output
floats.  Most likely there is enough capacitance to keep the
old value though.  If the second one turns on faster, and the
output value is changing, then you get a lot of current for
(hopefully) a very short time.

-- glen

Article: 144529
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: "jt_eaton" <z3qmtr45@gmail.com>
Date: Sun, 13 Dec 2009 13:47:09 -0600
Links: << >>  << T >>  << A >>
>
>wire a = b ? 1 : count[0];
>

And this differs from 

wire a = b || count[0];

How?


-----------------------------------------

However.... can all other manufacturers of LUT-based 
FPGAs make the same promise?  Again, *probably* yes; 
but would you bet your life/reputation/fortune on it?

-----------------------------------------

Thats the big problem with design for reuse. You have to design for the
lowest common denominator. I don't care what your new fpga family can do
unless it does it the same as everyone else.





Article: 144530
Subject: Re: Nintendo DS Screenshots / Video Capture
From: "Ste" <lordste2@hotmail.com>
Date: Sun, 13 Dec 2009 13:47:31 -0600
Links: << >>  << T >>  << A >>
>Thanks again chaps I'll keep you all updated so you can have a good
>chuckle at watching a noob stratch his head and do lots of stupid
>things :)!!!!!
>

Sorry for reviving an old thread, but I'm curious about how your project
went.  I need to start getting ready for my own senior design project (May
2011), and I'm thinking of something similar with the DS but not exactly
the same.  My goal would be to get an analog RGB/YPbPr output at 480i/p. 
Although getting the output is quite the task, my project's main focus
would be various selectable screen output modes.  For example:
Mode A) Top Screen only, 256 x 192 centered with black borders all around
Mode B) Bottom Screen only, 256 x 192 centered with black borders all
around
Mode C) Top Screen only, 256 x 192 resized to 640 x 480
Mode D) Top screen above Bottom screen, no gap between screens
Mode E) Top screen above Bottom screen, 64-line gap filled with
interpolated data from both screens and/or motion predicted pixels

and so forth....

This brings me to a few questions directed at anyone willing to answer. 
With all the extra DSP aspects of my desired features, would the Spartan-3
still be a good candidate for this project?  Or will I need something more
powerful?  I would like to be taking FFTs to help with the video scaling,
so I would prefer something capable of that.  But, I can avoid the
frequency domain altogether if the price difference for that capability is
too large.  Also, I would probably need to buffer more than one frame for
the gap interpolation, so wouldn't I need more RAM?  If I do need something
more powerful, then what is recommended?
I was actually looking at these two kits before I found this thread:
http://www.xilinx.com/products/devkits/HW-SPAR3A-SK-UNI-G.htm
http://www.xilinx.com/products/devkits/HW-SD1800A-DSP-SB-UNI-G.htm

Also, to add:
I've never used FPGAs before, but just like the author (of this thread) I'm
willing to put in most of my free time since I'm not able to take the FPGA
course at my school until Spring 2011 (which is too late).  A major goal of
this project is to learn about FPGAs.

Any tidbits of help on this would be greatly appreciated.  Thank you.



Article: 144531
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Dec 2009 20:07:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
jt_eaton <z3qmtr45@gmail.com> wrote:

>>wire a = b ? 1 : count[0];
 
> And this differs from 
 
> wire a = b || count[0];
 
> How?

It doesn't, but it isn't completely obvious, at least not
in an FPGA, what actually happens.  

-- glen

Article: 144532
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: Muzaffer Kal <kal@dspia.com>
Date: Sun, 13 Dec 2009 12:28:04 -0800
Links: << >>  << T >>  << A >>
On Sun, 13 Dec 2009 14:10:35 +0000, Symon <symon_brewer@hotmail.com>
wrote:

>Jonathan Bromley wrote:
>> On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke
>> <alfke@sbcglobal.net> wrote:
>> 
>>> In short:
>>> changing a SINGLE lut input will NEVER generate a glitch.
>> 
>> Nice to know, and - thinking about the likely structures
>> for the guts of a LUT - perfectly reasonable.  Thanks.
>> 
>> However.... can all other manufacturers of LUT-based 
>> FPGAs make the same promise?  Again, *probably* yes; 
>> but would you bet your life/reputation/fortune on it?
>
>Hi Jonathan,
>Think about it this way. If you deliberately wanted to make the output 
>of a 2^N to 1 mux glitch if only one select input changes, how would you 
>do it?

If your implementation comes out to be break before make, it's quite
easy to do. Assume the following implementation:

wire o = (!s & a) | (s & b).

 If the inverter is slow enough, both and gates will have their select
inputs low when s changes high to low.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144533
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 13 Dec 2009 12:36:21 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 13, 12:42=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:

> The OP's concern is legitimate,

But, as is usually the case with these types of queries, it's
indicative of either a flawed design approach or choosing to make your
own life more difficult.  The OP concern over performance that
prompted the query was after deliberately choosing to use a much lower
performance mode of operation than what was available...if you choose
to use a screwdriver to pound in nails when a hammer is available,
then why concern yourself with the performance differences between
between Phillips, Torx, or flat blade?

>
> I would assume that the other big FPGA company does it the same way.
> They are just not as forthcoming with helpful information.

I seem to recall that company A has documented this as well.  I seem
to recall running across it...but doubt that I would ever have a need
to make use of that little tidbit of info.

Kevin Jennings

Article: 144534
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: "dlopez" <d@designgame.ca>
Date: Sun, 13 Dec 2009 15:18:29 -0600
Links: << >>  << T >>  << A >>
>> The OP's concern is legitimate,
>
>But, as is usually the case with these types of queries, it's
>indicative of either a flawed design approach or choosing to make your
>own life more difficult.  The OP concern over performance that
>prompted the query was after deliberately choosing to use a much lower
>performance mode of operation than what was available...if you choose
>to use a screwdriver to pound in nails when a hammer is available,
>then why concern yourself with the performance differences between
>between Phillips, Torx, or flat blade?
>
>>
>> I would assume that the other big FPGA company does it the same way.
>> They are just not as forthcoming with helpful information.
>
>I seem to recall that company A has documented this as well.  I seem
>to recall running across it...but doubt that I would ever have a need
>to make use of that little tidbit of info.
>
>Kevin Jennings


I would have to disagree with you here. There are two modes of operation
for this chip:
a) Synchronous: One channel at ~25MB/s.
b) Asynchronous: Two channels of max ~10MB/s.

This means that the two modes are somewhat similar in terms of performance,
if one can achieve close to this maximum of 10MB/s. My application has a
streaming part, and a control part. Splitting the two makes software and
hardware developpement and architecture much easier. The 'control channel'
just works all the time, gives feedback about the status of the streaming
FIFO etc...while the 'streaming channel' doesn't have to deal with demuxing
commands out of the stream...

This sounds like a reasonnable decision, if I can live with the
asynchronous performance. In fact, I can, given I stay close to the 10MB/s.
I'm trying to find a circuit that will allow me to stay close to this,
without running at 500GHz, since I'm in a Spartan 3. Maybe 50M or 100M
would be good.

Even with the good news that the mux will not glitch, I failed to find a
circuit that would work...

If anybody has an idea, please let me know...

Diego
	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144535
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at ?one time?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Dec 2009 23:13:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
KJ <kkjennings@sbcglobal.net> wrote:
(Peter wrote)
 
>> The OP's concern is legitimate,
 
> But, as is usually the case with these types of queries, it's
> indicative of either a flawed design approach or choosing to make your
> own life more difficult.  The OP concern over performance that
> prompted the query was after deliberately choosing to use a much lower
> performance mode of operation than what was available...if you choose
> to use a screwdriver to pound in nails when a hammer is available,
> then why concern yourself with the performance differences between
> between Phillips, Torx, or flat blade?

We don't have all the details of the OP's project.  It might
the data source is asynchronous, and that asynchronous FIFO
is the best choice.  

-- glen

Article: 144536
Subject: Re: Xilinx's version of Quartus' Signaltap?
From: laserbeak43 <laserbeak43@gmail.com>
Date: Sun, 13 Dec 2009 15:20:12 -0800 (PST)
Links: << >>  << T >>  << A >>
I can't even get this simple code to work in the inserter

module two_input_xor (
	input wire in1,
	input wire in2,
	output wire out
	);
	assign out =3D in1 ^ in2;
endmodule


On Dec 9, 6:48=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> Andy Peters <goo...@latke.net> writes:
> > On Dec 7, 6:26=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> >> laserbeak43 <laserbea...@gmail.com> writes:
> >> > Hello,
> >> > =A0 =A0 I've just been shown Signaltap, A feature in Quartus Webpack
> >> > Edition. Does the Webpack Edition of ISE have this feature? WOW this
> >> > alone can convince me to use Altera products.
>
> >> Chipscope is the Xilinx equivalent - it's not in webpack (personally, =
I
> >> think that's a mistake on Xilinx's part)
>
> >> But comparing it to Signaltap may (IMHO) leave you underwhelmed... it'=
s
> >> very disjointed and unintegrated in comparison. =A0I'm still using FPG=
A
> >> editor to change which signals to monitor, then having to update the
> >> viewer by hand! V. tedious.
>
> > Really? What version of ChipScope are you using?
>
> 10.1.3
>
>
>
> > Use the ChipScope Core Inserter.
>
> Indeed, I could (and have in the past), but
>
> a) I'm using the EDK variety of core inserter, as it manages the JTAG
> linkages with the microblaze debug module for me
>
> b) I then have to run MAP, PAR, bitgen again.
>
> > All of the signals and elements of
> > the design are shown in it, and you simply choose the signals to
> > monitor. After you close the Inserter, go back to ISE, and re-fit.
>
> Re-fit - 10s of minutes.
>
> > From the ChipScope viewer, you can reconfigure the FPGA, then do an
> > "Import" which lets you bring in the names of all of the signals you
> > selected from the ChipScope Core Inserter project file.
>
> > No need to go into the FPGA editor at all!
>
> FPGAeditor, regenerate bitstream, 10s of seconds... =A0Then click "write
> CDC" button, import the result into the analyser. =A0Still tedious :)
>
> As I recall my experience with SignalTap (which was a while ago
> admittedly) I could select a signal from a dropdown list *in the
> Analyser* and it would do the tedious hacking that I currently do in
> FPGAed, regen the bitstream and upload it for me.
>
> Under some circumstances, it would redo a fit at that point, which was
> irritating, but at least I was able to do it all from the analyzer GUI,
> which was then always in sync with the FPGA.
>
> [Followups set to comp.arch.fpga, as it's not very Veriloggy]
>
> Cheers,
> Martin
>
> Crosspost & Followup-To: comp.arch.fpga
> --
> martin.j.thomp...@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w=
ww.conekt.net/electronics.html


Article: 144537
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: "jt_eaton" <z3qmtr45@gmail.com>
Date: Sun, 13 Dec 2009 17:27:21 -0600
Links: << >>  << T >>  << A >>

>
>If your implementation comes out to be break before make, it's quite
>easy to do. Assume the following implementation:
>
>wire o = (!s & a) | (s & b).
>
> If the inverter is slow enough, both and gates will have their select
>inputs low when s changes high to low.
>-- 

And to prevent glitches

wire o = (!s && a) || (s && b) ||  (a && b).


You may have to force your synthesis tool not to optimize out the redundant
logic.

	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144538
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 13 Dec 2009 15:32:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 13, 6:13=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

>
> We don't have all the details of the OP's project. =A0It might
> the data source is asynchronous, and that asynchronous FIFO
> is the best choice. =A0
>

I agree we don't have all the details, but he did post a link to the
part that he's interfacing with and that part has a synchronous mode
of operation that looks on the surface to be rather reasonable that
runs at ~6x faster (peak).  He's choosing to use the async mode of
operation for reasons having nothing to do with performance because it
simplifies other aspects.  That's fine, but when you do deliberately
give up chunks of performance for those reasons, don't quibble about
another 'additional' bit in order to have a robust design.

KJ

Article: 144539
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 13 Dec 2009 16:40:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 13, 4:18=A0pm, "dlopez" <d...@designgame.ca> wrote:
>
> I would have to disagree with you here. There are two modes of operation
> for this chip:
> a) Synchronous: One channel at ~25MB/s.
> b) Asynchronous: Two channels of max ~10MB/s.
>
> This means that the two modes are somewhat similar in terms of performanc=
e,

They don't seem that similar to me...

> if one can achieve close to this maximum of 10MB/s.

and it comes with a caveat.

> ...makes software and
> hardware developpement and architecture much easier.

I accept that there may be a benefit to your decision here, the price
being some amount of performance.  As I mentioned in the first post is
you have to do the analysis to see if the performance that you can get
from async is acceptable or not.  If it isn't, then making
"developpement (sic) and architecture much easier" is a moot point.

>
> This sounds like a reasonnable decision, if I can live with the
> asynchronous performance. In fact, I can, given I stay close to the 10MB/=
s.

Maybe ask what are the actual system consequences to 8...or 9?  So
much performance has already been left on the table already (30 MB/sec
USB sustained system is achievable with other chips and designs).

> I'm trying to find a circuit that will allow me to stay close to this,
> without running at 500GHz, since I'm in a Spartan 3. Maybe 50M or 100M
> would be good.
>

If I recall the spec numbers correctly, you need to guarantee a 50 ns
pulse width and 33 ns dead time.  Allowing 5 ns for Tco and another 5
ns for Tsu for the round trip means you need to generate a 60 ns
pulse.  An 80 MHz clock (12.5 ns period) would allow you to generate a
62 ns pulse with 37 ns dead time.  Two synchronizing flops adds 25 ns
for a total of 124 ns or an 8 MHz rate.  Since ultimate performance is
not your goal, cutting development time is (and that's fine, it can
result in getting product sooner), getting 8 MHz out of this
particular async interface is not too bad.

KJ

Article: 144540
Subject: Re: Initializing color bars on CH7301
From: "mmcshmi11" <mcamack@gmail.com>
Date: Sun, 13 Dec 2009 20:00:26 -0600
Links: << >>  << T >>  << A >>
Thanks a lot for your help with these settings. We finally got the color
bar output pattern to display via DVI. It came down to not having the right
timings on the DE line, it's amazing how precise everything has to be to
work.

I would like to post more info about using this chip after we get some
video data input, and hopefully output :)	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144541
Subject: Re: Data2MEM - finding the blockrams after PAR?
From: Eric Smith <spacewar@gmail.com>
Date: Sun, 13 Dec 2009 19:32:07 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks, Brian!  That's very helpful!

Eric

Article: 144542
Subject: XUPV5-LX110T, DDR2, and EDK (10.1 to be precise)
From: "mmcshmi11" <mcamack@gmail.com>
Date: Mon, 14 Dec 2009 02:54:25 -0600
Links: << >>  << T >>  << A >>
Hi everyone, there has been a lot of talk about this same question I'm
about to ask, but it is spread out over many different locations on the
internet and I can't find a real answer...

I am trying to interface the supplied 256MB DDR2 module (MT4HTF3264H-53E)
with the XUPV5-LX110T board. I'm using EDK 10.1 and I can add an MPMC core,
but the BSB only has the LX50T device listed, so when it runs MIG it
creates a UCF file that gives the following error when compiled:

------------------------------------------------------------------------------
ERROR:Place:713 - IOB component "fpga_0_DDR2_SDRAM_DDR2_DQ<13>" and
IODELAY
   component
 "DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/g
   en_dq[13].u_iob_dq/u_idelay_dq" must be placed adjacent to each other
into
   the same I/O tile in order to route net
 "DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/g
   en_dq[13].u_iob_dq/dq_in". The following issue has been detected: 
   Some of the logic associated with this structure is locked. This should
cause
   the rest of the logic to be locked.A problem was found at site
IODELAY_X0Y56
   where we must place IODELAY
 DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/ge
   n_dq[13].u_iob_dq/u_idelay_dq in order to satisfy the relative
placement
   requirements of this logic.  IODELAY
 DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/ge
   n_dqs[0].u_iob_dqs/u_iodelay_dq_ce appears to already be placed there
which
   makes this design unplaceable. 
------------------------------------------------------------------------------

There has been the suggestion that opening CORE generator and creating a
new MIG project (MIG v2.3 in my case) may work because it does contain the
LX110T device. However, this new file needs to have its LOC constraints
changed as well to specifically fit the XUPV5-LX110T board. Can somebody
point me in the right direction for fixing this, maybe I just need to learn
more about I/O tiles, banks, and what it means to have "Some of the logic
associated with this structure locked". 

ANY help would be greatly appreciated,
Thanks
	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144543
Subject: Re: Please Help me
From: Ben Jones <benjjuk@gmail.com>
Date: Mon, 14 Dec 2009 01:02:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 11, 6:07=A0pm, Mike Treseler <mtrese...@gmail.com> wrote:

> True, but it simplifies simulation having a reset
> for the input and output registers, even if (especially if ?)
> the rams and some shifters don't have one.

I agree that it's a Very Good Idea to have a reset, but I don't see
why it has to be an asynchronous one. By default I try to make
everything synchronous, including resets, unless there is a strong
case to do otherwise. I have found that this leads to fewer problems
throughout implementation.

       -Ben-

Article: 144544
Subject: Re: Cheapest way to get a chipscope compatible cable?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Mon, 14 Dec 2009 10:02:26 +0100
Links: << >>  << T >>  << A >>
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes:

> I always bug Xilinx on fairs to document the interfaces, but while

I would rather want the ability to add a plug-in at the software
level. I can program FPGA's fine with my Ethernet based "programming
cable", but I can't interface to chipscope and signaltap. A documented
USB interface would not be optimal in my case as I would have to make
a some kind of virtual USB device. It would be more optimal to have
some method at the Impact/quartus_pgm level to add a programming
hardware interface.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 144545
Subject: multiprocessors MB and shared BRAM
From: "ines_fr" <benhlima_ines@yahoo.fr>
Date: Mon, 14 Dec 2009 04:40:05 -0600
Links: << >>  << T >>  << A >>
hello,

I am using spartan 3 starter board (with MB7.1) to work with 2 processors
cores using EDK10.1 (my reference is the Xilinx tutorial XAPP996). I want
to add, between the two processors, a shared memory BRAM_block_v1_00_a with
the controler xps_bram_if_cntlr_v1_00_a.

the problem is: when I want to share the bus of the bram controller  SPLB,
changing the parameter C_SPLB_P2P to 0, nothing happens and the SPLB bus
does not connect the two buses mb_plb_0 and mb_plb_1 respectively of the
fist CPu and the the second.
if someone has an idea please help me because I'm stuck. :(
Thanks in advance

INES	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144546
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 14 Dec 2009 12:39:17 +0100
Links: << >>  << T >>  << A >>
On Sun, 13 Dec 2009 13:47:09 -0600, "jt_eaton" wrote:

>>wire a = b ? 1 : count[0];
>
>And this differs from 
>
>wire a = b || count[0];
>
>How?

Legibility?
Clarity of design intent?

Yes, I know these are niminy-piminy concerns that 
do not trouble Real Designers, but personally I'm
fairly happy to be a Quiche Eating Designer.  If 
there were more Quiche Eating and fewer Real 
Designers in the RTL business, I suspect the
verification business would be less able to find
work for me to do.

Cheers!
-- 
Jonathan Bromley

Article: 144547
Subject: Re: Cheapest way to get a chipscope compatible cable?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 14 Dec 2009 12:04:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp6@gustad.com> wrote:
> Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes:

> > I always bug Xilinx on fairs to document the interfaces, but while

> I would rather want the ability to add a plug-in at the software
> level. I can program FPGA's fine with my Ethernet based "programming
> cable", but I can't interface to chipscope and signaltap. A documented
> USB interface would not be optimal in my case as I would have to make
> a some kind of virtual USB device. It would be more optimal to have
> some method at the Impact/quartus_pgm level to add a programming
> hardware interface.

Interface was meant here as the software interface, API should have been
better uses instead of interface...  
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 144548
Subject: Re: Please Help me
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Mon, 14 Dec 2009 12:34:35 +0000
Links: << >>  << T >>  << A >>
On Mon, 14 Dec 2009 01:02:25 -0800 (PST), Ben Jones <benjjuk@gmail.com> wrote:

>On Dec 11, 6:07 pm, Mike Treseler <mtrese...@gmail.com> wrote:
>
>> True, but it simplifies simulation having a reset
>> for the input and output registers, even if (especially if ?)
>> the rams and some shifters don't have one.
>
>I agree that it's a Very Good Idea to have a reset, but I don't see
>why it has to be an asynchronous one. By default I try to make
>everything synchronous, including resets, unless there is a strong
>case to do otherwise. I have found that this leads to fewer problems
>throughout implementation.

For most of the design I would agree.

I confess I once had trouble with synchronous resets on clock generators,  DCMs
and the like. (The clock stops, so they never come out of reset.)

So there are occasional roles for asynch reset...

- Brian

Article: 144549
Subject: Video Processing
From: "Ghostboy" <Ghostboy@dommel.be>
Date: Mon, 14 Dec 2009 06:54:47 -0600
Links: << >>  << T >>  << A >>
Hi,

I want to send a video file from a pc to a FPGA (on a XUPV2P development
board) via the PCI interface. On the FPGA the video will be processed by an
algorithm. The result, after processing, will be send back to the pc. I
generated the VHDL-code of the algorithm in Simulink with Xilinx System
Generator (gateway_in and gateway_out are 8 bits wide). I also have the
VHDL-code of the PCI-core (from Xilinx). In Xilinx ISE I instantiated the
algorithm in the PCI-code. 

The resolution of the video is 320x240. The device driver on the pc (Linux)
gives an interrupt at the beginning of every frame. Can someone tell me how
I have to adapt the code of the user application delivered by Xilinx ( code
can be found here : http://www.mediafire.com/?kyygtdm0wlj ) to give the
FPGA a sign to start processing the data and send the result back to the pc
after a frame has been processed? Is there a manner to check how many
bits/bytes/pixels passed by?

Thanks in advance.






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