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 114925

Article: 114925
Subject: Re: Datapath design problem?
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 26 Jan 2007 08:46:17 -0800
Links: << >>  << T >>  << A >>


On Jan 25, 10:37 pm, "Shenli" <zhushe...@gmail.com> wrote:
> Hi all,
>
> I am reading "Coding Guidelines for Datapath Synthesis" from Synopsys.
>
> It says "The most important technique to improve the performance of a
> datapath is to avoid expensive carry-propagations and to make use of
> redundant representations instead (like carry-save or partial-product)
> wherever possible."
>
> 1. Is there any article talk about what's "carry-propagation" and how
> to avoid use it?
> 2. What's "redundant representations" mean?
>
> Please recommend some readings about it, thanks in advance!
>
> Best regards,
> Davy

http://www.ecs.umass.edu/ece/koren/arith/
Happy reading,


Article: 114926
Subject: Re: Forcing a LUT to not be optimized
From: "salorankatu" <salorankatu@gmail.com>
Date: 26 Jan 2007 09:15:37 -0800
Links: << >>  << T >>  << A >>
Hi,

I did something similar years ago to change the content of constant
multipliers. You can use the LOC, RLOC and BEL constraints. Also, for
reconfiguration I used JBits.

Regards,

Ivan

On Jan 26, 11:42 am, "JustJohn" <john.l.sm...@l-3com.com> wrote:
> On Jan 26, 7:34 am, "David" <dpmontm...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > I'm trying to create a design that uses a LUT to control routing on a
> > Virtex-II Pro.  It's pretty easy to create the LUT in VHDL and feed
> > it into a MUX to select the appropriate output based on the values in
> > the LUT.  I'm trying to use this in apartial reconfigurationdesign
> > so that I can change the values in the LUT with a partial bitstream to
> > change the routing.  My problem is that the design is optimized and
> > broken up in to multiple LUTs making it hard to determine what needs to
> > be changed.
>
> > Is there any way to force the LUT to be left as a primitive and
> > implement the equations (or initial value) that I set?  I would also
> > like to be able to force the LUT to be in known location so that I can
> > find it easily in the NCD file.  I've seen plenty of documentation
> > staying this can be done, I can't find any exampled.  I believe I can
> > use an RLOC but I'm not sure where the RLOC constraint should be
> > placed.
>
> > Thanks for your help,
>
> > David
>
> > Here's what I know so far:
>
> > library IEEE;
> > use IEEE.STD_LOGIC_1164.ALL;
> > use IEEE.STD_LOGIC_ARITH.ALL;
> > use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> > ---- Uncomment the following library declaration if instantiating
> > ---- any Xilinx primitives in this code.
> > library UNISIM;
> > use UNISIM.VComponents.all;
>
> > entity lut_mod is
> >     Port ( SW_0 : in  STD_LOGIC;  --just some simple inputs and
> > SW_1 : in  STD_LOGIC;               -- outputs for testing
> > SW_3 : in  STD_LOGIC;
> > LED_0 : out  STD_LOGIC;
> > LED_2 : out  STD_LOGIC;
> > LED_3 : out  STD_LOGIC);
> > end lut_mod;
>
> > architecture Behavioral of lut_mod is
>
> > signal LUT_to_MUX : STD_LOGIC;
>
> > begin
>
> >   LED_3 <= SW_1;
> >   LED_2 <= SW_0;
>
> > LUT4_L_inst : LUT4_L
> >    generic map (
> >       INIT => X"1010")
> >    port map (
> >       LO => LUT_to_MUX,      -- LUT local output
> >       I0 => SW_3,            -- LUT input
> >       I1 => SW_3,            -- LUT input
> >       I2 => SW_3,            -- LUT input
> >       I3 => SW_3             -- LUT input
> >    );
>
> > MUXF5_inst : MUXF5
> >    port map (
> >       O => LED_0,                    -- Output of MUX to general routing
> >       I0 => SW_0,            -- Input
> >       I1 => SW_1,            -- Input
> >       S => LUT_to_MUX        -- Input select to MUX
> >    );
>
> > end Behavioral;Read The Fine Manual.
> The Constraints Guide shows examples of RLOCs in both the architecture
> declaration area for single components and in the declaration area of
> for generate blocks for primitives created that way.
> Just John


Article: 114927
Subject: Re: Forcing a LUT to not be optimized
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: 26 Jan 2007 10:47:24 -0800
Links: << >>  << T >>  << A >>
The keywords are different for different synthesis tools. Look up the
user guide of your synthesis tool for words like "keep", "preserve",
"prune", etc. Once you find the right keyword, you can then attach it
as an attribute to your instance. eg
attribute SYN_NOPRUNE    of my_lut            : label  is TRUE;

Also the LOCK_PINS constraint may be useful.

Cheers,
Jim
http://home.comcast.net/~jimwu88/tools/


On Jan 26, 10:34 am, "David" <dpmontm...@gmail.com> wrote:
> Hi,
>
> I'm trying to create a design that uses a LUT to control routing on a
> Virtex-II Pro.  It's pretty easy to create the LUT in VHDL and feed
> it into a MUX to select the appropriate output based on the values in
> the LUT.  I'm trying to use this in a partial reconfiguration design
> so that I can change the values in the LUT with a partial bitstream to
> change the routing.  My problem is that the design is optimized and
> broken up in to multiple LUTs making it hard to determine what needs to
> be changed.
>
> Is there any way to force the LUT to be left as a primitive and
> implement the equations (or initial value) that I set?  I would also
> like to be able to force the LUT to be in known location so that I can
> find it easily in the NCD file.  I've seen plenty of documentation
> staying this can be done, I can't find any exampled.  I believe I can
> use an RLOC but I'm not sure where the RLOC constraint should be
> placed.
>
> Thanks for your help,
>
> David
>
> Here's what I know so far:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> ---- Uncomment the following library declaration if instantiating
> ---- any Xilinx primitives in this code.
> library UNISIM;
> use UNISIM.VComponents.all;
>
> entity lut_mod is
>     Port ( SW_0 : in  STD_LOGIC;  --just some simple inputs and
> SW_1 : in  STD_LOGIC;               -- outputs for testing
> SW_3 : in  STD_LOGIC;
> LED_0 : out  STD_LOGIC;
> LED_2 : out  STD_LOGIC;
> LED_3 : out  STD_LOGIC);
> end lut_mod;
>
> architecture Behavioral of lut_mod is
>
> signal LUT_to_MUX : STD_LOGIC;
>
> begin
>
>   LED_3 <= SW_1;
>   LED_2 <= SW_0;
>
> LUT4_L_inst : LUT4_L
>    generic map (
>       INIT => X"1010")
>    port map (
>       LO => LUT_to_MUX,      -- LUT local output
>       I0 => SW_3,            -- LUT input
>       I1 => SW_3,            -- LUT input
>       I2 => SW_3,            -- LUT input
>       I3 => SW_3             -- LUT input
>    );
>
> MUXF5_inst : MUXF5
>    port map (
>       O => LED_0,                    -- Output of MUX to general routing
>       I0 => SW_0,            -- Input
>       I1 => SW_1,            -- Input
>       S => LUT_to_MUX        -- Input select to MUX
>    );
> 
> end Behavioral;


Article: 114928
Subject: Re: Xilinx ISE 8.2
From: Eric Smith <eric@brouhaha.com>
Date: 26 Jan 2007 11:10:20 -0800
Links: << >>  << T >>  << A >>
I wrote:
> I do my editing in Emacs, but I despise vhdl-mode.  I normally use
> the GUI for everything but editing.

Martin Thompson <martin.j.thompson@trw.com> writes:
> Interesting - could you say any more about what makes vhdl-mode so
> bad?  My experience has been more of people thinking Emacs sucks, but
> they wish their editor did all that vhdl-mode does!

Completion/templates get in the way of my typing.  I know what I want
to write, but if the editor starts inserting stuff for me, I have to
think about the typing much more, so it slows me way down.

Eric

Article: 114929
Subject: Re: Timing Diagram Tool
From: "Patrick Dubois" <prdubois@gmail.com>
Date: 26 Jan 2007 11:17:47 -0800
Links: << >>  << T >>  << A >>
On Jan 25, 9:18 pm, "any2letters" <any2wil...@letter.com> wrote:
> Does anyone know a decent - FREE - timing diagram cad tool?
>
> Thanks

I'm using a Visio timing stencil from Thomas Thorsen:
http://kom.aau.dk/~ttho02/greyscale/TimingStencil/

Very good and free if you already have Visio...

Patrick


Article: 114930
Subject: Webpack-9.1 working on debian / grml
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Fri, 26 Jan 2007 19:38:35 GMT
Links: << >>  << T >>  << A >>
I downloaded Xilix webpack9.1 yesterday,
now tonight had some chance to play with it.

All works OK on my grml Linux system (Debian based, but with a thousand things
added).
Only thing I had to change was:
export LANGUAGE=usenglish
(Normally it shows 'us').
This to prevent endless warnings in command line mode.

Have only tested a little bit so far.

Nice work from Xilinx, install was much simpler then 8.1.

It is possible to switch between the old and new with some simple scripting.
It seems the old version uses libPds_Conv.so and the new one not....
Just relink the library path too, and run ldconfig.
 

Article: 114931
Subject: Re: Xilinx ISE 8.2
From: doug <doug@doug>
Date: Fri, 26 Jan 2007 11:45:49 -0800
Links: << >>  << T >>  << A >>
Ben Jones wrote:
> <ammonton@cc.full.stop.helsinki.fi> wrote in message 
> news:epb4ak$evj$1@oravannahka.helsinki.fi...
> 
>>doug <doug@doug> wrote:
>>
>>
>>>Memory leaks are due to sloppy or incompetent programmers.  Not fixing
>>>them is due to poor management.
>>
>>Obviously I can't speak for Xilinx, but IME some leaks are due to
>>design errors that can require whole subsystems to be rewritten to fix
>>properly.
> 
> 
> Entering the conversation rather late, but as an (internal) user of the ISE 
> tools and someone else who has seen their fair share of these memory issues, 
> I thought I ought to chime in. I'm not going to leap to the defence of the 
> ISE programmers and pretend that there are no problems, but I wanted to draw 
> attention to what I see as an important distinction between two similar but 
> separate issues:
> 
>  (1) Memory leaks, and
>  (2) Excessive memory consumption.
> 
> No-one will argue that problem (1) is acceptable in commercial production 
> software. However, a lot of the time what looks like a memory leak is really 
> just problem (2): an inefficient algorithm that consumes a massive amount of 
> memory when it runs, but is in fact perfectly well-behaved in terms of 
> returning memory to the system when it has finished with it. (Usually this 
> is a result of someone writing the simplest possible algorithm to get the 
> job done, not expecting it to become the critical section of code. I think 
> it's fair to say most of us have been guilty of that at one time or another! 
> :-))
> 
> Many times, I and other developers in my group have encountered excessive 
> runtimes and memory consumption for synthesizing quite simple pieces of HDL 
> code. Upon investigation, this has often turned out to be due to complexity 
> of coding style - for example, nested loops in VHDL function calls are a 
> common culprit. Usually there turns out to be a way to re-phrase the code in 
> question so that XST behaves better.
> 
> Often what seems to happen is that problems in class (2) are deemed 
> "annoyances" rather than defects, and thus get a lower priority than "real" 
> bugs that cause crashes or data corruption. Nevertheless, the bottom line is 
> that the more people who report that they're having problems, the more 
> likely something is to get fixed.
> 
> So please, carry on complaining... :-\
> 
>       -Ben- 
> 
> 
Just to be clear in this case here are the differences in 7.1 and  8 or
9 for the same project.
ISE 7.1 max memory useage about 120mB and 5 minutes
ISE89 crashes at 2GB after an hour.

This is definitely the memory leak category.  The other question, of
course is how they managed to write bad enough code to take 50 times
as long (when 8 or 9 crashes, it is about 25% done). Even if it did
not crash, this would be a major pain as it implies a xst process time
of around four hours.



Article: 114932
Subject: Re: Does xiling cpld's need a power supply bypass cap?
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Fri, 26 Jan 2007 14:07:24 -0600
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

>No, this is just history. On the old 7400 gates and MSI parts, Vcc and
>GRND were diagonally opposed, for no good reason (it actually gave max
>length to the bond wires, and thus max inductance.)
>One of the "Original Sins" of this industry. But remember, rise and
>fall times were >10 ns !
>  
>
The "good reason" is it made it possible to use REAL bus bars to distribute
power and ground on wire-wrap boards, and wide power/ground tracks
between rows of chips on 2-sided boards.  For 7400-series logic, the penalty
was really small, with 10 ns Tr - Tf.  As the move to faster and faster CMOS
happened, it got to be a problem.

Jon


Article: 114933
Subject: Re: video buffering scheme, nonsequential access (no spatial locality)
From: "wallge" <wallge@gmail.com>
Date: 26 Jan 2007 12:15:49 -0800
Links: << >>  << T >>  << A >>
I am not sure what you mean by two pass approach.
The max (theoretical) bandwidth I have available  to/from the SDRAM
is about
16 bits * 100 Mhz = 1.6 Gbit/sec

This is not an achievable estimate of course, even if I only did full
page
reads and writes, since there is overhead associated with each. I also
have to refresh periodically.

My pixel bit width could be brought down to 8 bits. That way I could
store 2
pixels per address if need be.



On Jan 25, 7:23 pm, "Pete Fraser" <pfra...@covad.net> wrote:
> "wallge" <wal...@gmail.com> wrote in messagenews:1169766685.898182.155950@v45g2000cwv.googlegroups.com...
>
> > Can you write out the FIR filter coeffs for
> > a bilinear interpolation "filter kernel"?
> > How about a bicubic interpolator filter kernel
> > what are its filter coeffs?I'm happy to, but we're getting away from FPGA stuff,
> so let's do that off line. Let me know how many phases you
> need, and the coefficient format you'd like. I usually
> use a minor 4x4 variation on cubic, but it's all set up in
> Mathematica, so I could do cubic also.
>
>
>
> > arguing semantics was not the purpose of my post.
>
> > I will probably wind up doing bilinear interpolation or
> > "filtering". Which means I need 4 pixels of the input frame to
> > determine
> > 1 pixel of output warped frame.So you don't really need coefficient tables for this.
> You can just use the fractional phase directly.
>
>
>
> > By the way what is the Freq response of the bilinear interpolation
> > "filter"?It depends on the position of output relative to input pixel, but
> for a central output pixel the frequency response would be
> Cosusoidal.
>
> Getting back to FPGA stuff though, what are your off-chip
> RAM bandwidth limitations, and could you consider a two-pass approach?
>
> >> I'm still not sure of your limitations on off-chip RAM.
> >> You have a buffer on the input or output (or both?)
> >> Do you have enough bandwidth to have an
> >> intermediate buffer for a two-pass operation?


Article: 114934
Subject: Re: Xilinx ISE 8.2
From: <steve.lass@xilinx.com>
Date: Fri, 26 Jan 2007 14:07:51 -0700
Links: << >>  << T >>  << A >>
Sean,

The first service pack is actually about 5 weeks after we freeze the DVD 
image and
release the software to manufacturing. After we feeze it, we give it to the 
FAEs and
train them on the new capabilities. Some customers may get it during this 
timeframe
if they have a specific need that is addressed in that release.  We also 
don't allow
any changes in the two weeks prior to RTM to allow for full testing. So even 
though
it looks like the first service pack comes out a couple of days after you 
get the software,
it's about 7-8 weeks after we lock down the release.

Regardless, because of these types of comments and the fact that we need to
better coordinate the releases of the other Xilinx tools, expect some 
positive changes
in 10.1 release cycle.

Steve

"Sean Durkin" <news_jan07@durkin.de> wrote in message 
news:51rd6fF1lppelU1@mid.individual.net...
> Hi Steve,
>
> first of all, I appreciate your comments.  I think I can say that actual
> Xilinx employees with an insight reading and posting here is really a
> "feature" most of us appreciate. :)
>
> steve.lass@xilinx.com wrote:
>> Actually, for the 9.1i release, feature freeze was in June 2006 and the
>> release to manufacturing was in December. We spend about 6 months fixing 
>> bugs
>> and improving quality.
> Then why do you release the first service pack days after the software?
> Why not just push back the release for a few weeks and ship something
> that is usable right away?
> I can't comment on other customers, but in our case it's not like we're
> desperately waiting for new ISE releases. It's not like we're waiting
> for those new features (because we usually don't have any idea what
> these new features might be, except the usual promised 30% increase in
> speed). It's not like we're waiting for bugs to be fixed... we have our
> workarounds, because we can't just wait until Xilinx fixes it, we need a
> solution now.
> It really is of no importance or relevance to us when a new ISE is
> coming out. When it's there, it's there, and we'll give it a try to see
> what's been changed/improved, hoping that some of the issues I had with
> earlier versions are resolved.
> As stated in my earlier post: I know of no other EDA software vendor who
> handles the release cycle like Xilinx does (and Xilinx didn't always do
> it like that either). And you really can't claim other vendors don't
> have the same problems with dependencies between different products and
> 3rd party software etc.
>
>> Yes, 7.1i had a new database and 8.1i had a new ProjNav GUI. The
>> database was created in 1990 and needed to be rewritten and so did the
>> GUI.
> I agree. The switch to QT (or whatever it is you're using now) was long
> overdue and made the GUI finally usable under Linux (be gone, WindU!).
>
>> It's not as simple as saying we will release when its ready because of 
>> other
>> dependencies. We need to make sure all of our other software products
>> (ChipScope, PlanAhead, System Generator, EDK, etc.), all of our IP, and
>> 3rd party tools all work together.
> Yes, you have to, but they don't. A new EDK version is usually not
> released for weeks or months after the corresponding ISE, so in most
> cases I can't use the latest ISE anyway because it won't work with my
> older EDK. Same applies for some IP (like MiG, for example): Those
> usually don't work right away as well, but they will be released
> sometime later in a version compatible with the latest ISE (BTW, the
> later IP-updates are a friggin' 600MB in size, helloooo?). So in what
> way does the fixed (and too early, quality-wise) release date help the
> integration of other products, IP and 3rd party tools?
>
>> Defining a release date and sticking to that
>> date is the best way to accomplish this. So instead, we define a feature
>> freeze date. If a feature can't be done by that date, it gets pushed to 
>> the next
>> release.
> I don't really understand this. Feature freeze date, yes. But why a
> fixed release date?
> Just to compare, look at the Debian Linux project (or any other bigger
> open source project). There's a feature freeze date, and a projected
> release date. At the feature freeze date, there's a certain number of
> release-critical bugs, and a number of not-so critical bugs. The release
> date usually will be pushed back until the number of release-critical
> bugs drops below a certain threshold, or is 0. Only then is it more or
> less guaranteed to work when it's released.
> I had assumed it is similar at Xilinx, but with a release date fixed
> well in advance, this can never work.
> I realize that software can never be bug-free, but that's beside the
> point. Why release a software that you *KNOW* has a bunch of critical
> bugs (you already have the first service pack ready!), just so the
> release date fits your regular release cycle?
> 3rd party tools as well as your other products and IPs are being worked
> on long before ISE is released, so the actual release date is of no
> relevance to those either.
>
>> I agree with all of this. To be honest, no customers told us they were 
>> using
>> partial reconfig in ISE 4 - 7, so we did not make it a priority.
> Well, I did. John Williams initiated a whole separate mailing list just
> for the topic. The subject regularly pops up in this very newsgroup. So
> you can't say noone told you. But I guess noone "important" told you,
> since all the people who used it until very recently were students or
> researchers, not high-volume-customers. But I totally understand that,
> this is not meant to be critizism. I guess it's pretty complicated to
> implement it in the software, and you can't expect a huge company doing
> all the work to fix it just for a handful of academic customers. Again,
> this is not meant to be sarcastic, I wouldn't do it any other way if I
> were in charge at Xilinx.
>
> The thing that bugs me is just that if it's not a priority for you to
> fix, why not just tell people? From ISE4 through ISE7, I was told "This
> is going to be fixed in the next service pack/release", but it never
> was. And after every new release, I invested a couple of days "porting"
> my designs to the new software, only to find out that it's still not
> working. A lot of time I could've spent smelling the roses or hugging
> trees or generally doing something useful if only I would've been told
> what's up right away.
>
>> Don't be shy about reporting bugs to us and don't
>> complain about bugs not being fixed if you don't report them.
> Most of the time I run into known problems. I first check your website
> and find that someone else has already reported it and "it will be fixed
> in the next service pack". But if you say duplicate reports might help
> prioritizing things, I'll start reporting.
>
>> Steve Lass
>> One of those Marketing guys.
> I apologize if my post read like I had something against marketing. :)
>
> It's just my experience that priorities and ways of thinking simply
> differ between "techies" and "marketing". I see it in our projects, too.
> Sometimes we have to implement features that are complete nonsense that
> no customer will ever use, but it looks good in the brochure and the
> competition has it in their brochures as well, so it's gotta be
> implemented; just in case a crazy customer decides to check if the
> brochure is totally accurate (which occasionally does happen)...
>
> I've had some interesting (and funny) chats with engineers from the
> competition at trade shows about the very same subject, and it's the
> same everywhere. The problem is that the people who decide which product
> will be bought often aren't "techies" and hence rely only on the
> brochures to compare, so it's gotta be in there. The question is who
> started it in the first place, who put it in the first brochure. :)
>
> And I'm not so sure how many of the new features are actually things
> customers need or want. I can't imagine any customer requesting the
> format of the project files to be switched to binary, or requesting the
> feature to send detailed information about my designs to Xilinx after
> synthesis... And I don't think a lot of customers need the "feature" of
> a new ISE release for christmas every year.
>
> cu,
> Sean
>
> -- 
> My email address is only valid until the end of the month.
> Go figure what the address is going to be after that... 



Article: 114935
Subject: Re: how do you code this?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Fri, 26 Jan 2007 14:33:59 -0800
Links: << >>  << T >>  << A >>
aravind wrote:
> 
> On Jan 26, 4:21 pm, David R Brooks <daveb...@iinet.net.au> wrote:
>> aravind wrote:
>>> There is a 20 bit counter,with two inputs ,on the rising edge of one
>>> input the counter must increment and on the rising edge of the other
>>> input the counter must decrement.
>>> this is for a 1MB FIFO buffer using single port external SRAM,I'm using
>>> Xilinx ISE tool.according to the xilinx tool you cannot have two
>>> (rising_edge()) statements in a single process.
>>> How do you code it?Are the two clocks synchronised? (I assume not, since you're building a
>> FIFO).
>> If not, such a circuit cannot be built. Consider what might happen when
>> the two clock edges occur almost simultaneously: the circuit will
>> certainly fail for some (small) delay between the clocks.
>> The usual way to build a FIFO is to use a separate counter for each
>> port. You can compare them to determine fullness. (Hint: use Gray-code
>> counters, not straight binary).
>>
>> If the clocks are synchronised, it may be possible to re-work the
>> circuit, so the counter sees a single clock, and an UP/HOLD/DOWN control
>> input. That is feasible.
> 
> Well the FIFO is not exactly asynchronous. Since i'm using a single
> port SRAM that sits outside the FPGA, it cannot handle a simultaneous
> read and write.I'm designing the state machine such that only one of
> the signals is asserted to the 20 bit counter at once.If i redesign the
> circuit to use a single clock with UP/HOLD/DOWN control ,i need to
> waste another clock cycle.i'm already using 2 clocks for read and 2
> clocks for a write operation to satisfy the timing requirements of the
> SRAM chip.The reason why chose to implement a counter instead of
> comparing the RD,WR addresses  is that, i can generate full, empty
> signals and also know to size of the buffer at any instant.
> 
Can you specify exactly what is meant by "not exactly asynchronous"? The 
whole thing may turn on that point: if there's a predictable 
relationship between those clocks, it can likely be exploited.
But nobody is building FPGA elements with multiple clock inputs: 
everything ultimately reduces to simple D-flipflops.

Article: 114936
Subject: Re: video buffering scheme, nonsequential access (no spatial locality)
From: "Gabor" <gabor@alacron.com>
Date: 26 Jan 2007 15:03:15 -0800
Links: << >>  << T >>  << A >>
On Jan 26, 3:15 pm, "wallge" <wal...@gmail.com> wrote:
> I am not sure what you mean by two pass approach.
> The max (theoretical) bandwidth I have available  to/from the SDRAM
> is about
> 16 bits * 100 Mhz = 1.6 Gbit/sec
>
> This is not an achievable estimate of course, even if I only did full
> page
> reads and writes, since there is overhead associated with each. I also
> have to refresh periodically.
>
> My pixel bit width could be brought down to 8 bits. That way I could
> store 2
> pixels per address if need be.
>

You may be missing an important feature of SDRAM.  You don't need to
use full-page reads or writes to keep data streaming at 100% of the
available bandwidth (if you don't change direction) or very nearly 100%
(if you switch from read to write infrequently).  This is due to the
ability
to set up another block operation on one bank while another bank is
transferring data.  When I use SDRAM for relatively random operations
like this I like to think of the minimum data unit as one minimal burst
(two words in a single-data-rate SDRAM) to each of the four banks.
Any number of these data units can be strung one after another
with no break in the data flow.  Then if you wanted to internally
buffer
a square section of the image in internal blockRAM the width
of the minimum block (allowing 100% data rate) would only be
16 8-bit pixels or 8 16-bit pixels in your case.  If the area can
cover the required computational core (4 x 4?) for several pixels
at a time, you can reduce overall bandwidth.  This was the point
of suggesting an internal cache memory.

HTH,
Gabor


Article: 114937
Subject: Re: Timing analyzer with Virtex 4
From: "skyworld" <chenyong20000@gmail.com>
Date: 26 Jan 2007 17:11:27 -0800
Links: << >>  << T >>  << A >>
Hi,

I think you are right. Do you have any advice on how to solve this?
should I add some constraints on this path? thanks.

On 1=D4=C226=C8=D5, =CF=C2=CE=E711=CA=B132=B7=D6, "Symon" <symon_bre...@hot=
mail.com>
wrote:
> "skyworld" <chenyong20...@gmail.com> wrote in messagenews:1169822495.6112=
26.116970@k78g2000cwa.googlegroups.com...
>
> > -----------------------------------------------------------------------=
---------
> > Slack:                  -0.443ns (requirement - (data path - clock path
> > skew + uncertainty))
> >  Source:               u_datarecovery_a6_i/FF0 (FF)
> >  Destination:          u_datarecovery_c5_i (FF)
> >  Requirement:          0.800ns
> >  Data Path Delay:      1.040ns (Levels of Logic =3D 0)
> >  Clock Path Skew:      -0.003ns
> >  Source Clock:         clk_180 rising at 0.000ns
> >  Destination Clock:    clk_90 rising at 0.800ns
> >  Clock Uncertainty:    0.200ns
>
> > I am confused by the slack: (requirement - (data path - clock path skew
> > + uncertainty)), Can any body help me to explain this? And how to
> > reduce this data path dealy? Seems my design fails with this.You've got=
 a FF clocked by clk_180 feeding a FF clocked by clk_90. There's
> only 800ps between these two edges, which is your clock period, 3.2ns *
> (180 - 90)/360 degrees. That leaves you a slack of 0.800 - 1.040 - 0.003 -
> 0.200ns. Just like it says.
> HTH, Syms.


Article: 114938
Subject: Re: Timing analyzer with Virtex 4
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 27 Jan 2007 01:30:55 -0000
Links: << >>  << T >>  << A >>
"skyworld" <chenyong20000@gmail.com> wrote in message 
news:1169860287.287589.165750@p10g2000cwp.googlegroups.com...
> Hi,

> I think you are right. Do you have any advice on how to solve this?

Yes. Don't try and clock two FFs 800ps apart.

> should I add some constraints on this path? thanks.

No. Change the path to something that's easier to meet.

HTH, Syms.



Article: 114939
Subject: Anyone have a Lancelot card for sale?
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri, 26 Jan 2007 21:26:02 -0800
Links: << >>  << T >>  << A >>
Sorry for the spam, but I wonder if there is anyone who has a fpga.nl 
Lancelot card they would consider parting with.  Since they switched 
from Alearep to Microtronix, they have gotten very expensive...

	-hpa

Article: 114940
Subject: Re: how do you code this?
From: "aravind" <aramosfet@gmail.com>
Date: 27 Jan 2007 00:01:27 -0800
Links: << >>  << T >>  << A >>


On Jan 27, 3:33 am, David R Brooks <daveb...@iinet.net.au> wrote:
> aravind wrote:
>
> > On Jan 26, 4:21 pm, David R Brooks <daveb...@iinet.net.au> wrote:
> >> aravind wrote:
> >>> There is a 20 bit counter,with two inputs ,on the rising edge of one
> >>> input the counter must increment and on the rising edge of the other
> >>> input the counter must decrement.
> >>> this is for a 1MB FIFO buffer using single port external SRAM,I'm using
> >>> Xilinx ISE tool.according to the xilinx tool you cannot have two
> >>> (rising_edge()) statements in a single process.
> >>> How do you code it?Are the two clocks synchronised? (I assume not, since you're building a
> >> FIFO).
> >> If not, such a circuit cannot be built. Consider what might happen when
> >> the two clock edges occur almost simultaneously: the circuit will
> >> certainly fail for some (small) delay between the clocks.
> >> The usual way to build a FIFO is to use a separate counter for each
> >> port. You can compare them to determine fullness. (Hint: use Gray-code
> >> counters, not straight binary).
>
> >> If the clocks are synchronised, it may be possible to re-work the
> >> circuit, so the counter sees a single clock, and an UP/HOLD/DOWN control
> >> input. That is feasible.
>
> > Well the FIFO is not exactly asynchronous. Since i'm using a single
> > port SRAM that sits outside the FPGA, it cannot handle a simultaneous
> > read and write.I'm designing the state machine such that only one of
> > the signals is asserted to the 20 bit counter at once.If i redesign the
> > circuit to use a single clock with UP/HOLD/DOWN control ,i need to
> > waste another clock cycle.i'm already using 2 clocks for read and 2
> > clocks for a write operation to satisfy the timing requirements of the
> > SRAM chip.The reason why chose to implement a counter instead of
> > comparing the RD,WR addresses  is that, i can generate full, empty
> > signals and also know to size of the buffer at any instant.Can you specify exactly what is meant by "not exactly asynchronous"? The
> whole thing may turn on that point: if there's a predictable
> relationship between those clocks, it can likely be exploited.
> But nobody is building FPGA elements with multiple clock inputs:
> everything ultimately reduces to simple D-flipflops.
The FIFO will be written by a UART which will get MP3 data from the
PC.The uart will use its own clock so that it is easy to generate the
standard baud rates.No matter whether the inputs to FIFO is synchronous
or asynchronous, the state machine is designed to synchronize the wr
and rd inputs and carry out a rd or wr operation.Hence the inputs to
the 20 bit counter will never be asserted at once, They will be atleast
(worstcase) 4 FIFO clocks apart.Thank you


Article: 114941
Subject: Re: xilinx 8.2 xps debug problems
From: Thomas Feller <tmueller@rbg.informatik.tu-darmstadt.de>
Date: Sat, 27 Jan 2007 12:56:05 +0100
Links: << >>  << T >>  << A >>
Ludwig Lenz wrote:
> Hi
> 
> I am working with an xilinx xup board. 8.2 sp1 ise + 8.2 edk.
> I am starting creating a design with ppc running from ddr ram, sysace and
> uart for output. Starting the debugger with:
> xmd -xmp system.xmp -opt etc/xmd_ppc405_0.opt
> with example application works.
> 
> Closing the project adding a new plb peripherial template with 4x32
> registers no interrupts. Reopening the project. Download bitstream.
> Starting the debugger again gives:
> 
> JTAG chain configuration
> --------------------------------------------------
> Device   ID Code        IR Length    Part Name
>  1       05059093          16        XCF32P
>  2       0a001093           8        System_ACE
>  3       0127e093          14        XC2VP30
> 
> 
> Unable to connect to PowerPC target. Invalid Processor Version No 0x00000000
> 
> make -f system.make clean doesn't help.
> 
> Any idea why the jtag autodetection fails after adding an core to the plb
> bus?
> 
> Thanks
> Ludwig

I only get this error if there is no bitstream downloaded to the FPGA.
Look if the red LED (D4 - DONE) near config DIP-switches is on.

HTH
    Thomas

Article: 114942
Subject: Re: Timing Diagram Tool
From: Terry Brown <tthkbw@yahoo.com>
Date: Sat, 27 Jan 2007 15:05:57 GMT
Links: << >>  << T >>  << A >>
I am curious if anyone has been able to make the drawtiming tool available
on sourceforge at http://drawtiming.sourceforge.net/ and referenced in
this thread, work on Cygwin.

I downloaded the tar file from sourceforge, and although a configure
script is reference, it is nowhere to be found.  It isn't in CVS either. 
I tried creating it with autoconf and the configure.in provided, but
although the configure script was created, it then failed.

I have tried contacting the author, but no response as yet.  

The tool looks interesting.

Terry Brown

On Fri, 26 Jan 2007 13:59:18 +0100, Koen Van Renterghem wrote:

> any2letters wrote:
>> Does anyone know a decent - FREE - timing diagram cad tool?
>> 
>> Thanks 
>> 
>> 
> 
> * Not free :
>     - http://www.syncad.com/
>     - If you are looking for something that helps you write 
> documentation, you can check a shareware tool called TimeGen 
> (http://www.xfusionsoftware.com/). Easy to use & not too expensive.
> 
> * Free tools :
>     - http://drawtiming.sourceforge.net/
>     - A latex package to insert timing diagrams, called 'timing', also 
> exists. (http://www.ctan.org/tex-archive/macros/latex/contrib/timing/)
>     - Check the 'other timing diagram' section on 
> http://tdv.sourceforge.net/ for a couple of interesting links.



-- 
C:\cygwin\home\tbrown\stickman_sig.txt

Article: 114943
Subject: Higher studies
From: "M Ihsan Baig" <mirzamihsan@hotmail.com>
Date: 27 Jan 2007 10:15:49 -0800
Links: << >>  << T >>  << A >>
Hi all experts,
Does any body tell me about the well known institues for fpga/asic 
study in Europe where I can start my MS leading to Ph.D
Thanks Beg


Article: 114944
Subject: Re: Forcing a LUT to not be optimized
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 27 Jan 2007 18:28:38 GMT
Links: << >>  << T >>  << A >>
I put together some Verilog code to send in to the Xilinx hotline just 
the other day to demonstrate a problem with FPGA Editor.  I digested my 
code down to the single LUT where I was having problems swapping pins. 
I manually instantiate the LUT whose function is to select the short 
routing path or the longer routing path for a fine-tuned delay.

I had problems keeping the Xilinx tools from optimizing the LUT back to 
a single pass-through rather than my mux of 2 versions of the same 
signal until I hit upon the "right" constraint.

LOCK_PINS as Jim Wu mentioned.

In the Xilinx User Constraints File (.ucf) you can specify everything 
you need in one line to have an explicit location and not have your INIT 
values optimized for you.

INST MyLut LOC = SLICE_X15Y34 | BEL = G | LOCK_PINS=ALL;

The LOC and BEL give you explicit placement to the same LUT compile 
after compile.  The LOCK_PINS=ALL keeps the optimizer from undoing your 
hand crafted details.  I even go as far as to use a LUT4 to specify a 
LUT3 function and leave one input out of the INIT values allowing me to 
use G1, G3, and G4 pins without using the G2, for instance.  I do my pin 
placement in the LUT instantiation rather than LOCK_PINS=A1:F2 type of 
syntax that gave me troubles early on.

Keep in mind you can also change the LUT contents by defining an SRL 
instead.  You still have fixed inputs (no LOCK_PINS required to keep the 
SRL in the right place) and you can reload the LUT over 16 clocks later 
on.  I considered this approach to get up to 4 different delays "tuned" 
to the silicon for one LUT but ended up sticking with a MUX of 2 values 
because I couldn't handle the 16 clocks of configuration.  An SRL with 
the same INIT as a LUT4 has the exact same function as the LUT4.

- John_H



David wrote:
> Hi,
> 
> I'm trying to create a design that uses a LUT to control routing on a
> Virtex-II Pro.  It's pretty easy to create the LUT in VHDL and feed
> it into a MUX to select the appropriate output based on the values in
> the LUT.  I'm trying to use this in a partial reconfiguration design
> so that I can change the values in the LUT with a partial bitstream to
> change the routing.  My problem is that the design is optimized and
> broken up in to multiple LUTs making it hard to determine what needs to
> be changed.
> 
> Is there any way to force the LUT to be left as a primitive and
> implement the equations (or initial value) that I set?  I would also
> like to be able to force the LUT to be in known location so that I can
> find it easily in the NCD file.  I've seen plenty of documentation
> staying this can be done, I can't find any exampled.  I believe I can
> use an RLOC but I'm not sure where the RLOC constraint should be
> placed.
> 
> Thanks for your help,
> 
> David
> 
> Here's what I know so far:
> 
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> 
> ---- Uncomment the following library declaration if instantiating
> ---- any Xilinx primitives in this code.
> library UNISIM;
> use UNISIM.VComponents.all;
> 
> entity lut_mod is
>     Port ( SW_0 : in  STD_LOGIC;  --just some simple inputs and
> SW_1 : in  STD_LOGIC;               -- outputs for testing
> SW_3 : in  STD_LOGIC;
> LED_0 : out  STD_LOGIC;
> LED_2 : out  STD_LOGIC;
> LED_3 : out  STD_LOGIC);
> end lut_mod;
> 
> architecture Behavioral of lut_mod is
> 
> signal LUT_to_MUX : STD_LOGIC;
> 
> begin
> 
>   LED_3 <= SW_1;
>   LED_2 <= SW_0;
> 
> LUT4_L_inst : LUT4_L
>    generic map (
>       INIT => X"1010")
>    port map (
>       LO => LUT_to_MUX, 	-- LUT local output
>       I0 => SW_3, 		-- LUT input
>       I1 => SW_3,		-- LUT input
>       I2 => SW_3, 		-- LUT input
>       I3 => SW_3 		-- LUT input
>    );
> 
> MUXF5_inst : MUXF5
>    port map (
>       O => LED_0,      		-- Output of MUX to general routing
>       I0 => SW_0,   		-- Input
>       I1 => SW_1,  	 	-- Input
>       S => LUT_to_MUX 	-- Input select to MUX
>    );
> 
> end Behavioral;

Article: 114945
Subject: Re: Forcing a LUT to not be optimized
From: "David" <dpmontminy@gmail.com>
Date: 27 Jan 2007 11:32:25 -0800
Links: << >>  << T >>  << A >>
Thank you all for your posts.  John_h, the combination of LOC BEL and 
LOCK_PINS works great for my application.


Article: 114946
Subject: Re: how do you code this?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Sat, 27 Jan 2007 13:39:56 -0800
Links: << >>  << T >>  << A >>
aravind wrote:
> 
> On Jan 27, 3:33 am, David R Brooks <daveb...@iinet.net.au> wrote:
>> aravind wrote:
>>
>>> On Jan 26, 4:21 pm, David R Brooks <daveb...@iinet.net.au> wrote:
>>>> aravind wrote:
>>>>> There is a 20 bit counter,with two inputs ,on the rising edge of one
>>>>> input the counter must increment and on the rising edge of the other
>>>>> input the counter must decrement.
>>>>> this is for a 1MB FIFO buffer using single port external SRAM,I'm using
>>>>> Xilinx ISE tool.according to the xilinx tool you cannot have two
>>>>> (rising_edge()) statements in a single process.
>>>>> How do you code it?Are the two clocks synchronised? (I assume not, since you're building a
>>>> FIFO).
>>>> If not, such a circuit cannot be built. Consider what might happen when
>>>> the two clock edges occur almost simultaneously: the circuit will
>>>> certainly fail for some (small) delay between the clocks.
>>>> The usual way to build a FIFO is to use a separate counter for each
>>>> port. You can compare them to determine fullness. (Hint: use Gray-code
>>>> counters, not straight binary).
>>>> If the clocks are synchronised, it may be possible to re-work the
>>>> circuit, so the counter sees a single clock, and an UP/HOLD/DOWN control
>>>> input. That is feasible.
>>> Well the FIFO is not exactly asynchronous. Since i'm using a single
>>> port SRAM that sits outside the FPGA, it cannot handle a simultaneous
>>> read and write.I'm designing the state machine such that only one of
>>> the signals is asserted to the 20 bit counter at once.If i redesign the
>>> circuit to use a single clock with UP/HOLD/DOWN control ,i need to
>>> waste another clock cycle.i'm already using 2 clocks for read and 2
>>> clocks for a write operation to satisfy the timing requirements of the
>>> SRAM chip.The reason why chose to implement a counter instead of
>>> comparing the RD,WR addresses  is that, i can generate full, empty
>>> signals and also know to size of the buffer at any instant.Can you specify exactly what is meant by "not exactly asynchronous"? The
>> whole thing may turn on that point: if there's a predictable
>> relationship between those clocks, it can likely be exploited.
>> But nobody is building FPGA elements with multiple clock inputs:
>> everything ultimately reduces to simple D-flipflops.
> The FIFO will be written by a UART which will get MP3 data from the
> PC.The uart will use its own clock so that it is easy to generate the
> standard baud rates.No matter whether the inputs to FIFO is synchronous
> or asynchronous, the state machine is designed to synchronize the wr
> and rd inputs and carry out a rd or wr operation.Hence the inputs to
> the 20 bit counter will never be asserted at once, They will be atleast
> (worstcase) 4 FIFO clocks apart.Thank you
> 
So the write side of the FIFO cannot be running much faster than 115/8 
kHz. How fast is the read-side clock? If it's dramatically faster, then 
just sample the UART outputs into the output clock domain, & do 
everything there. (ie re-synchronise the UART's ready line, & use the 
re-sampled edge to trigger a read of its data lines. Since RD & WR to 
most UARTs are asynchronous to the shift clock, the UART has done your 
work for you.

Article: 114947
Subject: Re: Higher studies
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Sat, 27 Jan 2007 22:49:45 +0100
Links: << >>  << T >>  << A >>
M Ihsan Baig wrote:

> Hi all experts,
> Does any body tell me about the well known institues for fpga/asic
> study in Europe where I can start my MS leading to Ph.D
> Thanks Beg

I'd try the University of Louvain-la-Neuve in Belgium. They have very good
contacts with IMEC, a major semiconductor research center. Plus, the beer
in the area is just wonderful.

Best regards,


Ben


Article: 114948
Subject: Re: Higher studies
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 27 Jan 2007 14:12:06 -0800
Links: << >>  << T >>  << A >>
Have a look at the FPL conference proceedings and pic a research group 
that suits your interessest.

Kolja Sulimma

On Jan 27, 10:49 pm, Ben Twijnstra <btwijns...@gmail.com> wrote:
> M Ihsan Baig wrote:
> > Hi all experts,
> > Does any body tell me about the well known institues for fpga/asic
> > study in Europe where I can start my MS leading to Ph.D
> > Thanks BegI'd try the University of Louvain-la-Neuve in Belgium. They have very good
> contacts with IMEC, a major semiconductor research center. Plus, the beer
> in the area is just wonderful.
>
> Best regards,
>
> Ben


Article: 114949
Subject: Re: Xilinx USB download cable
From: pbFJKD@ludd.invalid
Date: 27 Jan 2007 22:13:26 GMT
Links: << >>  << T >>  << A >>
Andy Peters <google@latke.net> wrote:
>On Jan 25, 11:31 am, Markus Fras <f...@mppmu.mpg.de> wrote:
>> Hello Ed McGettigan,
>>
>> that's sad to hear; we have three of the devices around at our company.
>> So what do we do with them, throw them in the bin and by new ones?

>Call your rep and demand that they supply you with supported
>replacements, gratis.

Another point why driver source is useful to have.

(the adapters may be slow & expensive, but if you got a few of them..well..)




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