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
2017JanFebMarApr2017

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 149700

Article: 149700
Subject: Re: What is the meaning of 'combinatorial path crossing multiple units'?
From: "HT-Lab" <hans64@ht-lab.com>
Date: Thu, 18 Nov 2010 08:47:03 -0000
Links: << >>  << T >>  << A >>

"shjin" <seunghun.jin@gmail.com> wrote in message 
news:07aef7e1-bb1b-4f98-95cd-af24ab4a96ad@k22g2000yqh.googlegroups.com...
> Hi, all.
>
> I got some error message when I use HDL Analysis and Lint (HAL) tool
> from Cadence on my design.
>
> It is,
> "Combinatorial path crossing multiple units drives a signal. The
> driver of flip-flop/output port has combinatorial assignment at
> multiple hierarchy levels."
>
> Since the code is just a normal register - combinational logic -
> register style, it seems usual to me.
>
> Can anybody explain why the analysis tool makes an error on this?

You seem to have a long combinatorial path going through multiple modules 
without a FF. This error message might be triggered by a HAL rule which states 
that each output (or input) port needs to be registered.  I would change this 
rule to a warning and when you come to synthesis and look at your critical path 
you might remember this warning :-)

Hans
www.ht-lab.com


>
> Thanks in advance.
>
> - shjin
> 



Article: 149701
Subject: Re: Does anyone have die sizes for Xilinx Virtex V devices
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 18 Nov 2010 10:35:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
phil <pcgarcia@wisc.edu> wrote:
> Hello all,
> I am currently a PhD student at the University of Wisconsin-Madison.
> I am working on research where I'm interfacing CPUs directly with
> reconfigurable logic.  Part of this work (and part of my thesis) is
> going to require me to have area estimates of portions of my interface
> system.  Having these estimates is useful for two reasons:  first, it
> allows me to better estimate the overhead (in terms of area) of the
> interface I've designed between the reconfigurable fabric and the
> cache hierarchy, and second, it will allow me to make better
> comparisons between using reconfigurable accelerators as compared to
> using other accelerator architectures such as vector processing units
> and GPUs.

> I would be most interested in Xilinx 65nm Virtex 5 devices (as the
> reconfigurable fabric I'm simulating in my research is assumed to be
> similar to the Virtex-5, and I use timing and area estimates for my
> accelerators using this device), in particular the LX 155 device,
> although any of them would likely prove to be useful for at least
> coming up with a ballpark estimate.  If this isn't available, I'd be
> open to other recent devices, as I could likely extrapolate an
> approximate area, which would allow me to make better educated guesses
> concerning the system.

> These numbers would be useful to my work even if I can't publish exact
> figures, but only rough estimate comparisons.   Any help would be
> greatly appreciated though.

Go to a dentist and X-ray some parts...
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

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

Article: 149702
Subject: Re: cool BGA pattern
From: 2cents <web@sharonmccormack.com>
Date: Thu, 18 Nov 2010 03:34:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 18, 1:58=A0am, "k...@att.bizzzzzzzzzzzz"
<k...@att.bizzzzzzzzzzzz> wrote:
> On Wed, 17 Nov 2010 09:03:54 -0800, Rob Gaddi <rga...@technologyhighland.=
com>
> wrote:
>
>
>
>
>
>
>
>
>
> >On 11/16/2010 4:06 PM, k...@att.bizzzzzzzzzzzz wrote:
> >> On Tue, 16 Nov 2010 14:23:22 -0600, Jon Elson<jmel...@wustl.edu> =A0wr=
ote:
>
> >>> On 11/14/2010 09:26 AM, Gabor wrote:
>
> >>>> I'll also agree that schematics are broken, at least since they
> >>>> dumped Aldec after Foundation version 4.1i. =A0It's pretty clear
> >>>> that schematics are very low on their software support priority
> >>>> list. =A0I stopped using schematics when I moved from the
> >>>> Aldec-based Foundation tools to ISE.
> >>> Actually, I thought the Aldec schematic tool was simply AWFUL, so bad=
 I
> >>> rigged up a system to use my preferred schematic entry (Protel 99) to
> >>> generate architectural VHDL. =A0It didn't make the VHDL quite the way
> >>> Xilinx wanted it, so I had to hand edit - mostly to remove redundant
> >>> duplications of library component declarations. =A0But, I've been slo=
wly
> >>> learning the benefits of all-VHDL development, so this is much less a=
n
> >>> issue now than it was for me almost a decade ago. =A0I still think th=
eir
> >>> ise schematic is pretty bad, only slightly better than Aldec's, which
> >>> seemsed like you could only get one gate and one FF on a page before =
the
> >>> automated wire generator went nuts. =A0Now, I can get 4 gates and 4 F=
Fs on
> >>> a page before the wiring gets messy. =A0I mostly only use schematics =
for
> >>> relatively simple, one-page glue logic for a CPLD, so it is OK.
>
> >> Schematics would be nice for high-level design where dataflows tend to
> >> dominate the reader's interest. =A0I've never seen a package that work=
ed well
> >> enough to use, though. =A0I just use schematics for board level. =A0I'=
ve always
> >> used VHDL only for programmable parts.
>
> >> OTOH, physical and logical viewers are useful to make sure synthesis i=
s doing
> >> what the designer expects, though. =A0The difference between such a vi=
ewer and a
> >> schematic entry package is the routing. =A0The viewer doesn't (well) a=
nd the
> >> schematic capture package won't (you do). =A0;-)
>
> >Having done some playing with the Aldec Active-HDL block diagram editor,
> >if you're in the market you may find it worth a look. =A0For doing actua=
l
> >schematic entry of low level blocks it's only mediocre, but for tying
> >together the high level stuff it's pretty quick and clean.
>
> Market? =A0Does it cost more than pocket lint? =A0The Aldec rep has been =
bugging
> me to do a test drive, but there zero chance of spending money on such th=
ings.
>
> The big advantage I see in schematic entry at the top level is documentat=
ion.
> Schematics are (well, can be) intuitive. =A0A pile of VHDL is very diffic=
ult to
> dig through. =A0Having had to verify a subsystem with a few hundred ~10K =
line
> files... =A0

You can do the reverse - write VHDL/Verilog and then get the schematic
viewer in ISE to draw a representation of it for documentation.
I've always thought it does a pretty good job of displaying the RTL
view and giving a way to look at the hookup of top-level modules.
PlanAhead can also generate schematics from the RTL source.
Note - I'm just offering it here as an idea to facilitate
documentation.

Article: 149703
Subject: Re: cool BGA pattern
From: "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz>
Date: Thu, 18 Nov 2010 19:19:37 -0600
Links: << >>  << T >>  << A >>
On Thu, 18 Nov 2010 03:34:10 -0800 (PST), 2cents <web@sharonmccormack.com>
wrote:

>On Nov 18, 1:58 am, "k...@att.bizzzzzzzzzzzz"
><k...@att.bizzzzzzzzzzzz> wrote:
>> On Wed, 17 Nov 2010 09:03:54 -0800, Rob Gaddi <rga...@technologyhighland.com>
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> >On 11/16/2010 4:06 PM, k...@att.bizzzzzzzzzzzz wrote:
>> >> On Tue, 16 Nov 2010 14:23:22 -0600, Jon Elson<jmel...@wustl.edu>  wrote:
>>
>> >>> On 11/14/2010 09:26 AM, Gabor wrote:
>>
>> >>>> I'll also agree that schematics are broken, at least since they
>> >>>> dumped Aldec after Foundation version 4.1i.  It's pretty clear
>> >>>> that schematics are very low on their software support priority
>> >>>> list.  I stopped using schematics when I moved from the
>> >>>> Aldec-based Foundation tools to ISE.
>> >>> Actually, I thought the Aldec schematic tool was simply AWFUL, so bad I
>> >>> rigged up a system to use my preferred schematic entry (Protel 99) to
>> >>> generate architectural VHDL.  It didn't make the VHDL quite the way
>> >>> Xilinx wanted it, so I had to hand edit - mostly to remove redundant
>> >>> duplications of library component declarations.  But, I've been slowly
>> >>> learning the benefits of all-VHDL development, so this is much less an
>> >>> issue now than it was for me almost a decade ago.  I still think their
>> >>> ise schematic is pretty bad, only slightly better than Aldec's, which
>> >>> seemsed like you could only get one gate and one FF on a page before the
>> >>> automated wire generator went nuts.  Now, I can get 4 gates and 4 FFs on
>> >>> a page before the wiring gets messy.  I mostly only use schematics for
>> >>> relatively simple, one-page glue logic for a CPLD, so it is OK.
>>
>> >> Schematics would be nice for high-level design where dataflows tend to
>> >> dominate the reader's interest.  I've never seen a package that worked well
>> >> enough to use, though.  I just use schematics for board level.  I've always
>> >> used VHDL only for programmable parts.
>>
>> >> OTOH, physical and logical viewers are useful to make sure synthesis is doing
>> >> what the designer expects, though.  The difference between such a viewer and a
>> >> schematic entry package is the routing.  The viewer doesn't (well) and the
>> >> schematic capture package won't (you do).  ;-)
>>
>> >Having done some playing with the Aldec Active-HDL block diagram editor,
>> >if you're in the market you may find it worth a look.  For doing actual
>> >schematic entry of low level blocks it's only mediocre, but for tying
>> >together the high level stuff it's pretty quick and clean.
>>
>> Market?  Does it cost more than pocket lint?  The Aldec rep has been bugging
>> me to do a test drive, but there zero chance of spending money on such things.
>>
>> The big advantage I see in schematic entry at the top level is documentation.
>> Schematics are (well, can be) intuitive.  A pile of VHDL is very difficult to
>> dig through.  Having had to verify a subsystem with a few hundred ~10K line
>> files...  
>
>You can do the reverse - write VHDL/Verilog and then get the schematic
>viewer in ISE to draw a representation of it for documentation.

That works for *very* small entities.  As I said in another post, this is
really useful for seeing what muck the synthesizer is making out of your code.
Synthesis uses "template matching" so one style of code *usually* produces one
sort of output.  These tools are great for discovering these templates.

>I've always thought it does a pretty good job of displaying the RTL
>view and giving a way to look at the hookup of top-level modules.

I haven't found this sort of thing useful at all.  The wires turn into
spaghetti on very simple designs.  The purpose of documentation is clarity,
not spaghetti.

>PlanAhead can also generate schematics from the RTL source.
>Note - I'm just offering it here as an idea to facilitate
>documentation.

Haven't used it.  Do you have a review?

Article: 149704
Subject: test peripheral example in xilinx XPS
From: "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com>
Date: Thu, 18 Nov 2010 22:48:09 -0600
Links: << >>  << T >>  << A >>
Hello all

I am using xilinx platform studio (XPS) for testing my FX12 minin module
development board and facing some problems.

Using base system builder, i select only RS232 and Mini module GPIO leds
and two examples were created,one test memory and second test
peripheral.Test memory resides in BRAM while test peripheral in DDR SDRAM.

I downloaded bit file to my board successfully for both memory and
peripheral examples one by one using xps download bitstream but problem is
that test peripheral example shows nothing (test memory example shows
correct results on hyperterminal).

I am quite new to xps and fpga, kindly guide me what can be the problem?I
guess it has to do something with executing code from external DDR SDRAM?

Thanks in advance 
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149705
Subject: Re: test peripheral example in xilinx XPS
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 18 Nov 2010 20:58:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 18, 10:48=A0pm, "bhatti"
<bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote:
> Hello all
>
> I am using xilinx platform studio (XPS) for testing my FX12 minin module
> development board and facing some problems.
>
> Using base system builder, i select only RS232 and Mini module GPIO leds
> and two examples were created,one test memory and second test
> peripheral.Test memory resides in BRAM while test peripheral in DDR SDRAM=
.
>
> I downloaded bit file to my board successfully for both memory and
> peripheral examples one by one using xps download bitstream but problem i=
s
> that test peripheral example shows nothing (test memory example shows
> correct results on hyperterminal).
>
> I am quite new to xps and fpga, kindly guide me what can be the problem?I
> guess it has to do something with executing code from external DDR SDRAM?
>
> Thanks in advance
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

Downloading the bitfile to the FPGA will not put the test peripheral
program into DDR memory for you. The simplest thing you can do is to
regenerate the linker script to put that program into BRAM memory so
that it will be downloaded with the rest of the bitfile.

What version of EDK/XPS are you using, and are you also using SDK?

Regards,

John McCaskill
www.FasterTechnology.com

Article: 149706
Subject: Re: What is the meaning of 'combinatorial path crossing multiple units'?
From: jc <jcappello@optimal-design.com>
Date: Fri, 19 Nov 2010 04:51:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 17, 6:58=A0pm, shjin <seunghun....@gmail.com> wrote:
> Hi, all.
>
> I got some error message when I use HDL Analysis and Lint (HAL) tool
> from Cadence on my design.
>
> It is,
> "Combinatorial path crossing multiple units drives a signal. The
> driver of flip-flop/output port has combinatorial assignment at
> multiple hierarchy levels."
>
> Since the code is just a normal register - combinational logic -
> register style, it seems usual to me.
>
> Can anybody explain why the analysis tool makes an error on this?
>
> Thanks in advance.
>
> - shjin

The warning seems to hint that you are driving an output port with a
combinatorial path that consists of multiple logic levels, which
correlates to longer flop-to-flop delays and slower performance. Good
practice to register that output port to (1) beef up performance, and
(2) to allow destination module that is receiving that signal to deal
with clk-to-out delay out of your module. Gives floorplanning more
flexibility as well. Do it now, or spend many hours during timing
closure later...
John

Article: 149707
Subject: Re: hot- or cold-plugging altera cyclone-3 LVDS inputs causing damage?
From: Thomas Entner <thomas.entner@entner-electronics.com>
Date: Fri, 19 Nov 2010 08:19:22 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

funny, we have a very similar setup here and also fried an LVDS-input
on a prototype... (Now, the n-input of the pair is low impedance to
ground). We came to the same conclusion (add ESD-protection in the re-
design)... So I am curios if there is an answer to your question.

Regards,

Thomas

www.entner-electronics.com

Article: 149708
Subject: Re: hot- or cold-plugging altera cyclone-3 LVDS inputs causing damage?
From: Chris Abele <ccabele@yahoo.com>
Date: Fri, 19 Nov 2010 20:46:08 -0500
Links: << >>  << T >>  << A >>
On 11/17/2010 6:26 PM, BW wrote:
> Hi!
>
> We have a design where an Altera Cyclone-3 (EP3C5) with LVDS inputs is
> connected to a sender on another board through a cable.
>
> In a number of cases on our prototype boards, the LVDS-inputs have
> been fried from this setup.
>
> Apart from any misdesign in the sender-board, does anyone have any
> suggestions on possible causes? Do these inputs have lesser ESD-
> protection? The cables used are shielded RJ45 TP-cables (ethernet
> cables) and I think the shield touches the connector before the
> signals, thus grounding away any accumulated potentials during
> assembly.
>
> I guess we'll put on external protection for the next board-spin, but
> I would just like some hints on if this is a common problem with these
> devices (if external protection is not used).
>
> Best regards,
> Bjorn W
>

I can imagine situations where a difference in ground levels between the 
two modules would cause trouble.  How are the grounds of the two modules 
related?  Are the modules powered from the same supply? (Like two boards 
in the same backplane, for example.)  If you disconnect the data cable 
between the two and connect a multimeter in current mode between the 
grounds is there any current flowing?

Probably not the issue, but easy to check.

Chris Abele


Article: 149709
Subject: Re: test peripheral example in xilinx XPS
From: "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com>
Date: Sat, 20 Nov 2010 00:56:15 -0600
Links: << >>  << T >>  << A >>

>Downloading the bitfile to the FPGA will not put the test peripheral
>program into DDR memory for you. The simplest thing you can do is to
>regenerate the linker script to put that program into BRAM memory so
>that it will be downloaded with the rest of the bitfile.
>
>What version of EDK/XPS are you using, and are you also using SDK?
>
>Regards,
>
>John McCaskill
>www.FasterTechnology.com
>
Thanks for your response.I am using EDK 10.1. No, i have not still used
SDK.Using BRAM i think i will face limited memory problem, secondly i want
to learn how to execute my code from external DDR SDRAM.



Thanks in advance	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149710
Subject: Multiple Reset Inputs
From: Analog_Guy <analog_guy@hotmail.com>
Date: Fri, 19 Nov 2010 23:09:03 -0800 (PST)
Links: << >>  << T >>  << A >>
I generally implement resets with asynchronous assertion and
synchronous de-assertion.  With a single reset, this is simple.
However, what happens if there are multiple reset inputs but I only
want one internal reset?

I was always under the impression that one should not have any
combinational logic in the asynchronous reset path, as it could lead
to static hazards (and reset glitches).  So, how do you combine two
resets into one without using combinational logic somewhere?

I was thinking of two scenarios:
1. AND the two resets coming into the FPGA, and connect to the
asynchronous reset of a synchronizer.  The output of the synchronizer
is the single internal reset.
2. Individually synchronize the two resets coming into the FPGA (note
that each reset input feeds the asynchronous reset of the
synchronizer).  AND the output of each of the synchronizers and feed
this single signal into the asynchronous reset of a final flip-flop.
The output of this flip-flop is the single internal reset.

In both cases we achieve asynchronous assertion and synchronous de-
assertion ... however, in both cases there is combinational logic in
the asynchronous reset path.

Any suggestions how these multiple resets should be combined?

Article: 149711
Subject: Spartan3 device with long availability
From: Thomas Heller <theller@ctypes.org>
Date: Sat, 20 Nov 2010 10:27:16 +0100
Links: << >>  << T >>  << A >>
I have to develop some electronics that will probably fit nicely into
a spartan3 device xc3s200 or xc3s400.  Which series / package should
I choose for long availability?

I am considering the TQFP144 or PQ208 package, I try to avoid BGA.
Will there be any differences in the long-term availability
between spartan 3, spartan 3A, spartan 3E, or even spartan 3AN?

Thanks,
Thomas

Article: 149712
Subject: Re: Spartan3 device with long availability
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Sat, 20 Nov 2010 04:03:13 -0800 (PST)
Links: << >>  << T >>  << A >>
>  I try to avoid BGA.

Don't.
It has many advantages over the other packages,
among them
- better yield in soldering.
- less EMI
- less ground bounce
- less board space
- better cooling

Kolja

Article: 149713
Subject: Re: Spartan3 device with long availability
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sat, 20 Nov 2010 13:12:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
Thomas Heller <theller@ctypes.org> wrote:
> I have to develop some electronics that will probably fit nicely into
> a spartan3 device xc3s200 or xc3s400.  Which series / package should
> I choose for long availability?

> I am considering the TQFP144 or PQ208 package, I try to avoid BGA.
> Will there be any differences in the long-term availability
> between spartan 3, spartan 3A, spartan 3E, or even spartan 3AN?

No hints for availability, but 3E and 3A configure from cheap commodity
serialflash and 3A and 3AN can run with only 3.3/1.2 Volt, while S3 and S3E
always need 2.5 Volt.

Otherwise S2 was introduced around 2000, but still seems running strong, so
thi may indicate whats happening with S3...
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

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

Article: 149714
Subject: Re: Spartan3 device with long availability
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sat, 20 Nov 2010 13:13:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
Kolja Sulimma <ksulimma@googlemail.com> wrote:
> >  I try to avoid BGA.

> Don't.
> It has many advantages over the other packages,
> among them
> - better yield in soldering.
> - less EMI
> - less ground bounce
> - less board space
> - better cooling

And if you go th BGA, you might now consider S6.
S6 in QFP still is _not_ available...
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

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

Article: 149715
Subject: Huffman encoder/Decoder For Text data compression
From: "kude" <tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sat, 20 Nov 2010 07:57:14 -0600
Links: << >>  << T >>  << A >>
Huffman encoder/Decoder For Text data compression

Hi All,
  I am working on Huffman Encoder/Decoder for text    
  compression/Decompression.And here are the things not clear for me.
1.How can I give text input (Whole text once) to the FPGA.
2.When I encode the data the output code length is not fixed and how can I

  manage this with constant I/O pins of the FPGA.
3.When Encoding the text I have to use heaps,Sort and mearge but this
things  
  are not synthesizable in FPGA

    thanks in advance	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149716
Subject: Re: Multiple Reset Inputs
From: Michael Karas <mkaras@carouselDASHdesign.com>
Date: Sat, 20 Nov 2010 06:55:28 -0800
Links: << >>  << T >>  << A >>
In article <63d8c432-53dd-43c0-9541-e87ee1645090
@q14g2000yqe.googlegroups.com>, analog_guy@hotmail.com says...
> I was thinking of two scenarios:
> 1. AND the two resets coming into the FPGA, and connect to the
> asynchronous reset of a synchronizer.  The output of the synchronizer
> is the single internal reset.

You really want to OR the two resets together. Either one _or_ the other 
should reset the internal logic. The sense of the logic may be H active 
or L active but in any case the combinatorial logic is an OR. 

Now I say this because in all my experience I cannot envision a case 
where you would be saying you want to reset your internal logic when 
both inputs are active at the same time. 

Lastly, what is wrong with some combinatorial logic in the asynchronous 
path? Since the inputs arrive at who knows what time the added delay of 
the combinatorial logic only adds a small amount to that best guess 
time! Now I suppose there could be special cases of the input signals 
being very narrow pulses where the delay may be an impact but then they 
are going to have problems being detected by the synchronizer - but you 
did not mention that detail.


-- 

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com

Article: 149717
Subject: Re: Spartan3 device with long availability
From: Gabor <gabor@alacron.com>
Date: Sat, 20 Nov 2010 07:44:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 20, 8:12=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> Thomas Heller <thel...@ctypes.org> wrote:
> > I have to develop some electronics that will probably fit nicely into
> > a spartan3 device xc3s200 or xc3s400. =A0Which series / package should
> > I choose for long availability?
> > I am considering the TQFP144 or PQ208 package, I try to avoid BGA.
> > Will there be any differences in the long-term availability
> > between spartan 3, spartan 3A, spartan 3E, or even spartan 3AN?
>
> No hints for availability, but 3E and 3A configure from cheap commodity
> serialflash and 3A and 3AN can run with only 3.3/1.2 Volt, while S3 and S=
3E
> always need 2.5 Volt.
>
> Otherwise S2 was introduced around 2000, but still seems running strong, =
so
> thi may indicate whats happening with S3...
> --
> Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar=
mstadt.de
>
> Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

S3A is the newest of the S3 series, and likely to survive longest.  It
is
also cheapest per LUT.  I would stay away from the S3AN which is a
die-stack FPGA / SPI flash combo.  You can do the same thing with
a very inexpensive external SPI flash chip, and you don't have to
worry about Xilinx's own long term arrangement to obtain the stacked
flash device.

S3A also has some architectural advantages over the older versions
including better IDELAY elements, but be careful to read the I/O
restrictions, because part of the price reduction was to make the
top/bottom banks have different subsets of the I/O capabilities than
the left/right banks.  If you can get all of the I/O you need in the
available packages, then the S3A is probably the best choice.

Regards,
Gabor

Article: 149718
Subject: Re: Huffman encoder/Decoder For Text data compression
From: Gabor <gabor@alacron.com>
Date: Sat, 20 Nov 2010 07:49:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 20, 8:57=A0am, "kude"
<tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> Huffman encoder/Decoder For Text data compression
>
> Hi All,
> =A0 I am working on Huffman Encoder/Decoder for text =A0 =A0
> =A0 compression/Decompression.And here are the things not clear for me.
> 1.How can I give text input (Whole text once) to the FPGA.
> 2.When I encode the data the output code length is not fixed and how can =
I
>
> =A0 manage this with constant I/O pins of the FPGA.
> 3.When Encoding the text I have to use heaps,Sort and mearge but this
> things =A0
> =A0 are not synthesizable in FPGA
>
> =A0 =A0 thanks in advance =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

There are some publicly available JPEG compression cores if I'm not
mistaken.  Part of the core is a Huffman encoder.  You might want
to check this out to see how it can be done.

I have worked on a JPEG compression core, but only to optimize it
to meet timing, so I'm not up on all the details.  However I remember
that at one point in the interface the data path had to become very
wide to handle the worst case expansion, and then there is a lot
of shifting and packing that grabs the required bits from the wide
path.  The latter was a part I worked on extensively, and it
required a lot of pipelining to meet timing.

Regards,
Gabor

Article: 149719
Subject: Re: test peripheral example in xilinx XPS
From: Newman <newman5382@yahoo.com>
Date: Sat, 20 Nov 2010 09:19:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 20, 1:56=A0am, "bhatti"
<bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote:
> >Downloading the bitfile to the FPGA will not put the test peripheral
> >program into DDR memory for you. The simplest thing you can do is to
> >regenerate the linker script to put that program into BRAM memory so
> >that it will be downloaded with the rest of the bitfile.
>
> >What version of EDK/XPS are you using, and are you also using SDK?
>
> >Regards,
>
> >John McCaskill
> >www.FasterTechnology.com
>
> Thanks for your response.I am using EDK 10.1. No, i have not still used
> SDK.Using BRAM i think i will face limited memory problem, secondly i wan=
t
> to learn how to execute my code from external DDR SDRAM.
>
> Thanks in advance =A0 =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

You can load the code into DDR sdram using XMD.
If you have a compact flash system, an ACE file can load DDR SDRAM for
you.
If you have non-volatile memory, a boot loader program in BRAM can
move the executable from nvmem to DDR.

You should read the tutorials and manuals.

Article: 149720
Subject: Debugging with a single LED
From: Philip Pemberton <usenet10@philpem.me.uk>
Date: 20 Nov 2010 23:22:48 GMT
Links: << >>  << T >>  << A >>
Here's a good mind bender for the gurus...

I have a device with an FPGA and a PIC microcontroller (among other 
things). The two communicate over a 12-line link:
  8 multiplexed data/address lines -- can be In or Out
  2 Address Load lines -- low and high. Inputs to the FPGA.
  Read and Write -- inputs to the FPGA

I can make these outputs or inputs on the PIC, and can do the same on the 
FPGA. The I/O state above is simply how they're configured in the 
"working" hardware.

Problem is, the boards I'm getting back from manufacturing have really 
shoddy yields. 70% failure rate. I'm getting bridges and opens, nearly 
always on the PIC-to-FPGA lines. Anyway, enough of that. Suffice it to 
say, I have a stack of almost-working boards with various issues. Visual 
inspection is not finding them, and shotgun-resoldering the PIC and FPGA 
tends to cause more problems.

Basically: I need to find the shorts and opens, and fix them, without 
affecting the rest of the pins (which I assume to work). In order to do 
this, I need to know where those shorts and opens are.

Problems:
  1) I don't know which pins work. I can't even guarantee that any of 
them work.
  2) The only real output the FPGA has is an LED
  3) I'd like to find as many shorted pins as possible in each test pass. 
If I can find and eliminate them all, so much the better.

So far the best idea I've come up with (actually a friend came up with 
it) is to load a bitstream which reads the state of the other 10 lines. 
The FPGA clocks out 20 '0' bits, a '1', then the state of the 10 pins. 
This allows the PIC/PC combination to automatically test the whole set of 
remaining combinations.

Can anyone think of an easier way to do this?

Thanks,
-- 
Phil.
usenet10@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year

Article: 149721
Subject: Re: Multiple Reset Inputs
From: Allan Herriman <allanherriman@hotmail.com>
Date: 21 Nov 2010 00:09:53 GMT
Links: << >>  << T >>  << A >>
On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:

> [snip]
> Lastly, what is wrong with some combinatorial logic in the asynchronous
> path? Since the inputs arrive at who knows what time the added delay of
> the combinatorial logic only adds a small amount to that best guess
> time! Now I suppose there could be special cases of the input signals
> being very narrow pulses where the delay may be an impact but then they
> are going to have problems being detected by the synchronizer - but you
> did not mention that detail.

The OP is worried about glitches in the combinatorial logic.  In general, 
a glitch can be generated at the output of some combinatorial logic 
whenever any input changes, even if (under steady state conditions) that 
input should not affect the output.

For the specific case of an AND (or OR) gate implemented in a single LUT, 
glitches can not be generated and the OP needn't worry.

There's an old Xilinx appnote dating from the XC3000 days which stated 
that a single LUT will not generate an glitch if only one input changes 
at a time (i.e. within some brief time window).  This behaviour was due 
to the structure of the readback mux in the LUT.  I believe I have seen a 
similar statement from Altera as well, although this information never 
appears in contemporary datasheets from either company.

Guaranteeing glitch free behaviour from synthesised logic with more than 
a few inputs is nigh on impossible, as the synth tool will ignore any 
hazard coverage you do.

Cheers,
Allan

Article: 149722
Subject: Re: [O.T.] Audio DAC as AWG (test source)?
From: "Ala" <alackrity@comcast.net>
Date: Sat, 20 Nov 2010 19:14:45 -0500
Links: << >>  << T >>  << A >>

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:poednSAUkb9tRlLRnZ2dnUVZ7v6dnZ2d@lyse.net...
>
> If you get an appropriate DAC (such as the AD5791) with an SPI interface, 
> you could connect it up to an FTDI FT4232H module.


 I am not recommending you get their services 


Article: 149723
Subject: Re: Debugging with a single LED
From: Allan Herriman <allanherriman@hotmail.com>
Date: 21 Nov 2010 00:22:25 GMT
Links: << >>  << T >>  << A >>
On Sat, 20 Nov 2010 23:22:48 +0000, Philip Pemberton wrote:

> Here's a good mind bender for the gurus...
> 
> Problems:
[snip]
>   2) The only real output the FPGA has is an LED

When I worked at Fujitsu, we had a controller board with a GPIO driven 
status LED on its front panel.  When it was in debug mode (e.g. after a 
crash), software on the target system would implement a bit-bashed UART 
and send the resulting bits to the LED.  We had a little gizmo with a 
phototransistor and an line-powered RS232 buffer that would send the bits 
back to a serial port on a PC so the debug results (in this case a stack 
trace) could be seen on a terminal emulator program.  A magnet in the 
gizmo held it on to the panel in the right place above the LED.

You shouldn't have any trouble rolling your own UART to do something 
similar.  If it's a Xilinx part, I recommend a picoblaze + picoblaze uart 
combination if there's more than a trivial amount of information to send.

Cheers,
Allan

Article: 149724
Subject: Re: Multiple Reset Inputs
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 20 Nov 2010 18:11:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 20, 7:09=A0pm, Allan Herriman <allanherri...@hotmail.com> wrote:
> On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:
> > [snip]
> > Lastly, what is wrong with some combinatorial logic in the asynchronous
> > path? Since the inputs arrive at who knows what time the added delay of
> > the combinatorial logic only adds a small amount to that best guess
> > time! Now I suppose there could be special cases of the input signals
> > being very narrow pulses where the delay may be an impact but then they
> > are going to have problems being detected by the synchronizer - but you
> > did not mention that detail.
>
> The OP is worried about glitches in the combinatorial logic. =A0In genera=
l,
> a glitch can be generated at the output of some combinatorial logic
> whenever any input changes, even if (under steady state conditions) that
> input should not affect the output.
>

Actually, the OP is worried about something that does not need to be
worried about.  Glitches causing resets are things that need to be
avoided when you're trying to *prevent* a false reset from occurring
(i.e. resetting when you don't want to be).  What the OP describes is
two inputs which are supposed to cause a reset.  A 'glitch' on one of
them would be a case of something that should cause a reset, not
something that should be prevented.

KJ



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
2017JanFebMarApr2017

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