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 113450

Article: 113450
Subject: Re: more of ERROR:MapLib:661
From: "chriskoh" <chrisdekoh@yahoo.com>
Date: 13 Dec 2006 18:24:12 -0800
Links: << >>  << T >>  << A >>
Hi,
   that is the problem. the report doesn't say anything much. I traced
any opb_intc_0/Intr<1>, and it is driven by the interrupt signal from
the uart block. this will work fine if it is connected standalone.

Chris

VC wrote:
> <snip>
>
> Its not a matter of resources.
>
> As the error message says -
> " output
> signal=opb_intc_0/opb_intc_0/INTC_CORE_I/INTR_DET_I/interrupts<1> has
> input
> signal "opb_intc_0/Intr<1>" which will be trimmed.  See the trim report
> for details about why the input signal will become undriven"
>
> The signal - opb_intc_0/Intr<1> is undriven due to some reason; you
> need to figure that out why and see what needs to be changed.
> 
> HTH.


Article: 113451
Subject: Re: FPGA : Async FIFO, Programmable full
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 14 Dec 2006 03:56:40 GMT
Links: << >>  << T >>  << A >>
"bijoy" <pbijoy@rediffmail.com> wrote in message 
news:eea0fde.-1@webx.sUN8CHnE...
> Hi In designing asynchronous FIFOs we have to use Gray code read/write 
> pointers.
>
> And while using gray code I know how to generate full and empty flags.
>
> But i would like to get ideas from experienced designers how to generate 
> Programmable full or programmable empty flags
>
> Thanks in advance
>
Not to put a damper on the thread but I've found that there are probably 
very few applications for true programmable fifo flags inside a programmable 
chip that can be in-system updated like an FPGA.  By 'programmable flag' I'm 
assuming that we're talking about having some register that can be written 
to with some arbitrary number that will cause some associated fifo status 
flag to trigger when it reaches that level.  This arbitrary number is in 
some fashion controlled by software and is not and can not be known a 
priori.

There are applications where I'd like a flag to go off at 'almost full' or 
'almost empty' but those 'almost' conditions have always been able to be 
determined as hard fixed constants.  Maybe those levels are things like 7/8 
or 321/456 or .01 (just making up numbers here) but the point is that the 
point where I want a fifo flag to trigger has (for me at least) always been 
traceable back to known system parameters.  It could be that the trigger 
level is some bizzarro function of those system parameters but the end 
result is a known fixed number so generally what I will do is code the 
bizzarro function into the VHDL that instantiates the fifo to produce the 
constant that will be input as a generic input to the fifo that uses it to 
determine the flag status trigger levels.

True programmable flags where some outside software comes in and actually 
tells the fifo what specific level to trigger at came about back when fifos 
were mostly implemented as discrete parts and the suppliers of these little 
gens of course would have virtually no market for parts that trigger at 
levels like 7/8 or 321/456 or .01 so instead they came up with a mechanism 
to allow the user to program in an arbitrary level...which they did....and 
always (in my experience) did so with some constant that was determined from 
system parameters.

For those applications that fit the cases I've described and really can have 
fixed constants to determine possibly bizzaro trigger levels there is no 
need for any convoluted math or moving gray code to binary to do math.  Your 
gray code counter that keeps track of the depth is a finite state machine, 
there is exactly one state that needs to be matched to see if it corresponds 
to the equivalent of being 321/456 full.

If someone does have an application that really requires true programmable 
flags I'd be interested to hear about it.  The environment though is
- Fifo is inside a programmable part.
- That programmable part can be updated in system.

Presumably this would have to mean that the trigger levels can not be 
determined either empirically at design/design verification time or as a 
function of known system parameters but would (presumably) have to be a 
dynamic function of what is going on in a particular system at a particular 
time (i.e. something unique to the particular system at that point causes 
the software to go 'Woooah, I need to change that fifo trigger level from 
321/456 to 7/8 (or some such)'.

KJ 



Article: 113452
Subject: Re: How does FPGA tools infer FIFO
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 14 Dec 2006 05:47:05 GMT
Links: << >>  << T >>  << A >>
ashish.dobhal@gmail.com wrote:
> In the presence of numerous styles for designing asynchronous FIFOs,
> how does FPGA synthesis tools infer the FIFO specified in RTL?
> 
> Thanks in advance.
> 
> Ashish

I know of no tool that infers FIFOs, async or synchronous.

Tools infer shift registers and dual-port memories (1 Write, 1 or more 
Reads) fine.  Shift registers can be used in FIFOs.  The FIFOs still 
need coding for address control and flag generation.  Without that 
coding there would be no chance of inference.  Since there are so many 
ways to code the address and control, there probably is no standard 
inference.  If the architecture supports hard FIFOs, instantiate them or 
generate them from the vendor's tools.

Article: 113453
Subject: CMI Coder/ Decoder
From: "Volker" <jreeg@gmx.de>
Date: Thu, 14 Dec 2006 07:32:15 +0100
Links: << >>  << T >>  << A >>
Hello,
did anyone know how to realize a CMI Coder/Decoder in a FPGA (preferred in 
VHDL). Thanks for answers an tipps.
Volker 



Article: 113454
Subject: Re: what are your current SoC design for ?
From: "Marco T." <mmm@mmm.com>
Date: Thu, 14 Dec 2006 07:35:31 +0100
Links: << >>  << T >>  << A >>

<rponsard@gmail.com> ha scritto nel messaggio 
news:1166010235.979393.32660@16g2000cwy.googlegroups.com...
>I don't need your IP secrecies...
>
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...
>
> thanks,
> raph
>

Chip customization VS asic project.

Marco 



Article: 113455
Subject: Re: approximation of an exponential ramp?
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 13 Dec 2006 23:04:26 -0800
Links: << >>  << T >>  << A >>
On 10 Dec 2006 13:15:40 -0800, burn.sir@gmail.com wrote:

>
>In an interview from 97, Bob Yannes the designer of MOS 6581 (aka
>"SID") said the following aboud the chips ASDR enveloper:
>
>"In order to more closely model the exponential decay of sounds,
>another look-up table on the output of the Envelope Generator would
>sequentially divide the clock to the Envelope Generator by two at
>specific counts in the Decay and Release cycles. This created a
>piece-wise linear approximation of an exponential. I was particularly
>happy how well this worked considering the simplicity of the circuitry.
>The Attack, however, was linear, but this sounded fine."
>
>In short, he was using an down-counter to count down from 255 down to
>some number, but he somehow made the counter to move
>pseudo-exponentially instead of linearly.
>
>Does anyone know how this works?
>
>
>burns
>
>
>(the whole interview is found at
>http://stud1.tuwien.ac.at/~e9426444/yannes.html)


You can model a simple exponential decay:

Given integer N in a register, iterate...

N = N - K * N

where K < 1.

One simple value for K is 0.5. So N drops in half every iteration. A
little less severe is .25 (right shift 2) or 0.125 (shift 3) etc.

The smaller K, the more this looks like an exponential decay, and the
slower it decays. It won't ever get to zero unless you compute to more
bits than you actually use, namely throw away some LSB guard bits.

John






Article: 113456
Subject: Re: electrical interface problem LVPECL - LVDS multi-inputs
From: "Kurt Kaiser" <diebombeausdemwesten@freenet.de>
Date: Thu, 14 Dec 2006 08:15:05 +0100
Links: << >>  << T >>  << A >>

"Andy" <jonesandy@comcast.net> schrieb im Newsbeitrag 
news:1166052157.531419.185640@l12g2000cwl.googlegroups.com...
> Why do you need to connect the same clock to more than one clock input
> on your FPGA? What kind of FPGA are you using?
>
> If I had to buffer and translate, I would rather translate, then
> buffer. Unless you are very careful with your resistors and
> interconnect, a resistor translator may not work too well.
>
> Andy

Thanks so far for your answer. I'm using Virtex-4 FX60. Depending on the 
implemented designs I will use either the clock input on one side or the 
other, not both the at the same time of course. So I'm hoping for more 
flexibility and freedom of clock routing if I have two clocks available and 
stick to the one that fits better from design to design. The FPGA's input is 
LVDS.



Article: 113457
Subject: Re: . What is the sign-and-magnitude of the following 4's complement
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 13 Dec 2006 23:42:59 -0800
Links: << >>  << T >>  << A >>
Brian Drummond wrote:

> On 12 Dec 2006 05:41:46 -0800, paulcullen@purewebsites.co.uk wrote:

>>What is the sign-and-magnitude of the following 4's complement
>>number? (Leave answer in base 4).

(snip)

> Be aware that the answer depends on the word size - if it's a 16 bit
> number I'd give one answer; if it's larger (say 32 bit) I'd give another
> answer.

You mean 8 quits, not 16 bits.

bits, trits, quits, quints, ...

-- glen


Article: 113458
Subject: Re: Ones' complement addition
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 13 Dec 2006 23:49:30 -0800
Links: << >>  << T >>  << A >>
Koen Van Renterghem wrote:

> Hi,
> 
> I'm trying to devise an efficient method to generate a ones' complement
> sum of two 16 bit integers in a single cycle. I'm targeting a Xilinx
> device and right now I'm using a 32 bit adder. Suppose I want to add x
> and y :

You need the end-around carry.  It is pretty easy with a carry
lookahead adder to wire the carry out back to the carry in.

(snip)

You should only need a 16 bit adder with carry in/carry out.

How about:

assign {carry,result} = a+b+carry;

The worst case is where the carry propagates 16 bits.
(Well, the full width.)  It never goes farther than that.

-- glen


Article: 113459
Subject: Re: Avoiding meta stability?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 14 Dec 2006 00:02:43 -0800
Links: << >>  << T >>  << A >>
Symon wrote:

(snip)

> Weeeelll, yes and no! I was just trying to make a point that there is a 
> finite probability that the lights will stay red until the drivers drop dead 
> of old age. Not exactly safe! Nearly, but not exactly. :-) Likewise, the 
> PDP-10 console lights _could_ stop for months.
> So, I would respectfully disagree with your statement that "The solution to 
> metastability is asynchronous logic (also called self-timed logic).". 
> Furthermore, the implication that synchronous design is any worse than 
> asynchonous design I think is not true. As Mike said in his post, "The 
> D-flop is also an asynchronous circuit.".

There is also a finite probability that all the air molecules in
the room will move to the other half of the room.  Like metastability
the solution is also exponential.

If you have a mechanical traffic controller, cams springs and such,
then it might last that long.  Electrical I don't think so.

Not so long after I learned about metastability, among others
that the lower probability of getting to the metastable state
the longer it stays when it gets there, I was in a shower with
a valve with a spring to turn off when you release it.  It would
turn such that it would go over the cam to the other side.
I managed to get it to stop right on top, the metastable state,
long enough to finish a shower.

-- glen


Article: 113460
Subject: Re: what are your current SoC design for ?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 14 Dec 2006 21:09:02 +1300
Links: << >>  << T >>  << A >>
rponsard@gmail.com wrote:
> I don't need your IP secrecies...
> 
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...

There are two levels of softCPU apps :
a) The tiny ones, where the code fits inside the FPGA, in BRAM.
b) The larger ones, that need external code memory.

For a) the SoftCPU comes almost for free, and can be used to
handle less time-critical tasks, and give a degree of
programmability to all the other FPGA coded peripherals.
Or they may be DSP(s), doing focused tasks.

Unless you need ADCs / DACs, or similar peripherals, these
do meet the lower footprint consideration.

For b) once you have to add Code memory, you've lost the 'single chip', 
and the interface between the memory/fpga is poor for RFI & pin count.

  Now it's becomes less clear-cut on which is better, and
the choice swings somewhat, as each alternative goes thru
generation cycles, or as code size changes.
  If your code CAN fit into an external 32 bit uC, and meet
speed targets, the tight local bus Code-CPU, gives the uC
quite an edge.
  Better 32 bit uC now have DMA SSC channels, so FPGA
interfaces can have low pin counts, and they have quite
impressive FLASH resource, so the SoftCPU can struggle
against this growing option.
Leading example: Atmels upcomming AT91SAM9XE512 Flash uC.

  Once your app gets so large (MBytes), that is has outgrown uC Flash,
and it needs SDRAM to run, then it swings more balanced.
SDRAM uC are appearing, but not widely yet (example: AT91SAM9263),
and both choices have PCB traces to SDRAM, so there less of a clear edge.

Also, show your students this:
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670

Details are presently sketchy, but a large dual port memory that was not 
niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs.

-jg




Article: 113461
Subject: Re: Question about metastability that's been on my mind for a while
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 14 Dec 2006 00:09:50 -0800
Links: << >>  << T >>  << A >>
nospam wrote:
(someone wrote)
>>>What about injecting noise in the FF feedback loops which is small 
>>>enough not to alter their (static)performance, but large enough to drive 
>>>the feedback loops (and maybe schmitt triggers) into clipping and thus 
>>>their stable state ?

> It is an idea I proposed before, without any claim that it would reduce the
> occurence metastable states only that it would reduce their duration.

As I understand it, the area under the (probability of going metastable) 
vs. (time staying metastable) tends to be constant.  It might be that
you can change the distribution enough to make it more useful.

-- glen


Article: 113462
Subject: Re: Problem with connecting higher order address lines of SDRAM to FPGA
From: "Amirtham" <amirtham@microview-tech.com>
Date: 14 Dec 2006 00:15:44 -0800
Links: << >>  << T >>  << A >>
I am re-posting this, since I have not got any response from anyone...
If somebody can help me solve this problem.. please...

Even if I remove my SDRAM controller completely and just keep sending
NOPs to SDRAM with A9, A10, A11 connected, the board hangs. so I think
the problem is not with the Controller code... It is somethingelse that
I might have missedout.

thanks
Mohni.

Amirtham wrote:
> Thanks for your response.
>
> I am making
>
> 1) A10 = 0 for READ and WRITE to disable AUTO-PRECHARGE since I am
> using burst transfer.
>
> 2) A10 = 1 for PRECHARGE command to precharge all the banks.
>
> Thanks!!!
>
>
> Ben Jackson wrote:
> > On 2006-12-08, Amirtham <amirtham@microview-tech.com> wrote:
> > >
> > > If I access SDRAM using address lines sdr_A8 to sdr_A0, I am able to
> > > access one row 100% correct without error. My problem starts if I
> > > connect sdr_A11, sdr_A10, sdr_A9. Board hangs.
> >
> > Do you understand the special function of A10 for READ and WRITE commands?
> > What is your address logic for read and write?
> >
> > -- 
> > Ben Jackson AD7GD
> > <ben@ben.com>
> > http://www.ben.com/


Article: 113463
Subject: Re: NOR Flash Controller
From: "lbo_user" <shareef.jalloq@lightblueoptics.com>
Date: 14 Dec 2006 00:27:52 -0800
Links: << >>  << T >>  << A >>
Sorry, I should have said.  This is going to be using synchronous burst
mode components.


Article: 113464
Subject: Re: NOR Flash Controller
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 14 Dec 2006 00:51:22 -0800
Links: << >>  << T >>  << A >>
lbo_user wrote:
> Sorry, I should have said.  This is going to be using synchronous burst
> mode components.

That makes the interface simpler (once in synchronous mode), but if you
read the datasheet, the devices power up (and end up after reset) in
**asynchronous** mode. You have to write the control register to get
them to operate in synchronous mode.

I use these devices (and have for some time), and all this is in the
datasheet.

Either get a core (there are a number of them around) or roll your own
FSM taking into account the current mode of the flash device.

Cheers

PeteS


Article: 113465
Subject: Re: NOR Flash Controller
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 14 Dec 2006 01:01:27 -0800
Links: << >>  << T >>  << A >>
PeteS wrote:
> lbo_user wrote:
> > Sorry, I should have said.  This is going to be using synchronous burst
> > mode components.
>
> That makes the interface simpler (once in synchronous mode), but if you
> read the datasheet, the devices power up (and end up after reset) in
> **asynchronous** mode. You have to write the control register to get
> them to operate in synchronous mode.
>
> I use these devices (and have for some time), and all this is in the
> datasheet.
>
> Either get a core (there are a number of them around) or roll your own
> FSM taking into account the current mode of the flash device.
>
> Cheers
>
> PeteS

Let me correct myself here:

The majority of parallel flash devices (NOR), even when listed as
synchronous devices, actually start up in asynchronous burst mode.

Intel Strata flash (which sets the standard, whether we like it or not,
and therefore most other players are 'compatible') start in this mode -
asynchronous, burst of [up to] 8. As I noted, read the datasheet for
the device type you want to use.

Cheers

PeteS


Article: 113466
Subject: query
From: "ram" <vsrpkumar@rediffmail.com>
Date: 14 Dec 2006 01:07:46 -0800
Links: << >>  << T >>  << A >>
Hi
I am working in a design.I am using altera cyclone IC.My design works
fine.One problem is whenever it is brought near to LCD it become noisy
and stop working.What i have to do.I kept slew rate slow for the output
pins and bidirectional low.Can anyone give idea.
kumar


Article: 113467
Subject: SDRAM in SPARTAN 3E
From: "Pablo" <pbantunez@gmail.com>
Date: 14 Dec 2006 01:44:34 -0800
Links: << >>  << T >>  << A >>
Help!!!!!!!!! Hi, How can I write data into the ddr sdram with
Microblaze and the OPB DDR. The SDRAM is 16MX16 and I have only found
how can I test this memory. Can anyone tell me something about this????


Article: 113468
Subject: Re: Virtex4 : cleaner signals?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 14 Dec 2006 10:02:18 -0000
Links: << >>  << T >>  << A >>
"John" <seabass950@yahoo.com> wrote in message 
news:eea0f8b.6@webx.sUN8CHnE...
>I am using a digital scope and triggering on rising edge. I do a single 
>sample and use two cursors to measure the reflection.
>
> One side of the probe is on the pin, the other side is on ground.
>
> BTW, 50 ohm source terminator cleaned up the data lines a lot (lowest it 
> drops to now is 2.9V), but my 25mhz clock signal still has a lot of noise, 
> since I didn't design my interface board to have a source terminator on 
> the clock.

Hi John,
Check your probe is grounded correctly. The 6in wire with a croc clip 
doesn't cut it at today's rise times.

Look for "Sensitivity To The Probe Ground Wire" in this article.
http://www.sigcon.com/Pubs/straight/probes.htm


This guy has a cool website and shows you how to make your own probe in 
pictures! (I'm pretty sure I saw him once cycling the other way on the Los 
Gatos creek trail ["ON YOUR LEFT!"], but that's another story!)
http://www.emcesd.com/1ghzprob.htm


Also, there's a difference between noise and reflections. For example, if 
you use your digital scope in infinite persistence mode, noise will make all 
the traces get thicker vertically as the noise is not correlated to the 
clock signal you're measuring. On the other hand, reflections are the same 
for every clock cycle so the traces stay thin. It may help diagnose your 
problem if you can say which of these is your problem.

HTH, Syms. 



Article: 113469
Subject: Re: NOR Flash Controller
From: "lbo_user" <shareef.jalloq@lightblueoptics.com>
Date: 14 Dec 2006 02:38:03 -0800
Links: << >>  << T >>  << A >>
Thanks Pete,

I'm happy with the functionality of the flash, I'm more concerned with
the amount of effort needed to write my own controller.  The majority
of the work looks to be in the program/erase polling state machines.
I'm just really short on time and have been looking for faster
alternatives to writing my own controller.  It's looking more and more
like that's the way I'll have to go though.

Ta.


Article: 113470
Subject: Re: How does FPGA tools infer FIFO
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 14 Dec 2006 10:46:04 GMT
Links: << >>  << T >>  << A >>

"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:tz5gh.7746$Li6.5593@trndny03...
> ashish.dobhal@gmail.com wrote:
>> In the presence of numerous styles for designing asynchronous FIFOs,
>> how does FPGA synthesis tools infer the FIFO specified in RTL?
>>
>> Thanks in advance.
>>
>> Ashish
>
> I know of no tool that infers FIFOs, async or synchronous.
>
You must be using very primitive tools.  Altera, Xilinx and Synplify (and 
probably most other major players) certainly do.

As to the original question there probably aren't really that many 'styles' 
as you may think.  One time through whatever part of the tool chain it is 
that takes the raw source code and converts it to something equivalent but 
easier for the downstream tools to chew on and those supposedly numerous 
styles likely all pop out looking the same.  Remember, no matter how you 
code it, the functionality of the fifo isn't changing.

After all, there are many ways to code just a flip flop and the tools can 
recognize all of those as well so you could rightly ask the same question 
about how the tools detect a flip flop.

KJ 



Article: 113471
Subject: Re: FPGA : Async FIFO, Programmable full
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Thu, 14 Dec 2006 14:52:44 +0200
Links: << >>  << T >>  << A >>
KJ wrote:
> 
> If someone does have an application that really requires true programmable 
> flags I'd be interested to hear about it.  The environment though is
> - Fifo is inside a programmable part.
> - That programmable part can be updated in system.

I have many examples from telecom side. For example if you have some universal
interface card, that has each port configurable to different protocol (for
example STM1/4/16). That kind of big change in speed usually needs some changes
in fifo limits to get maximum efficiency. If you have for example 8 ports that
would need quite many different FPGA images to cover static settings. Also
partial reconfiguration in my opinion is little too dififficult way to handle
this problem.

Of course you can code the static values for each protocol and use mux to select
one of them to the fifo comparison logic. But it's easier just to add
one register and let the software to handle the values. Also usually maximum
efficiency needs some lab testing to find the optimal fifo values. And waiting
hours for new fpga after each change in the limits is not fun.

I have used programmable flags so many times in lab while debugging different
problems in the design, and while trying to understand the dynamics how different
limits affect interconnected fifo fystems between chips etc.


--Kim

Article: 113472
Subject: Re: How does FPGA tools infer FIFO
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Thu, 14 Dec 2006 15:18:31 +0200
Links: << >>  << T >>  << A >>
KJ wrote:

>>I know of no tool that infers FIFOs, async or synchronous.
>>
> 
> You must be using very primitive tools.  Altera, Xilinx and Synplify (and 
> probably most other major players) certainly do.

As far as I know they don't. That would be quite an accomplishment. I quickly
checked Synplify Premiere 8.6.2 manual and there was nothing about inferring
FIFOs. Also Mentor Precicsion 2006a Synthesis Style Guide did not tell about
fifo inference. And also Xilinx 8.2i xst manual did not have any text about fifo
inferring. Could you point me to the right page in manuals?

Completely other thing is lpm_fifo and different DW_*fifo* components. But they
must be instantiated directly. Same applies to coregen, altera megafunctions etc.

--Kim

Article: 113473
Subject: Re: Ones' complement addition
From: Koen Van Renterghem <Ih8teSpam@intec.ugent.be>
Date: Thu, 14 Dec 2006 15:20:01 +0100
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
 > Koen Van Renterghem wrote:
 >
 >> Hi,
 >>
 >> I'm trying to devise an efficient method to generate a ones' complement
 >> sum of two 16 bit integers in a single cycle. I'm targeting a Xilinx
 >> device and right now I'm using a 32 bit adder. Suppose I want to add x
 >> and y :
 >
 > You need the end-around carry.  It is pretty easy with a carry
 > lookahead adder to wire the carry out back to the carry in.
 >
 > (snip)
 >
 > You should only need a 16 bit adder with carry in/carry out.
 >
 > How about:
 >
 > assign {carry,result} = a+b+carry;
 >
 > The worst case is where the carry propagates 16 bits.
 > (Well, the full width.)  It never goes farther than that.
 >
 > -- glen
 >
I previously tried this approach, but that resulted in synplify and 
xilinx complaining about a combinatorial loop created by connecting the
carry-out to the carry-in of the adder. That is why I started using a
dedicated 16 bit adder to calculate the carry. This carry is then
applied to a second adder.

The statement you suggested will save area, but is there a proper way to
constrain it? Right now the combinatorial loop seems to be ignored in 
timing analysis :

<snip>
1 logic loop found and disabled.

   ----------------------------------------------------------------------
  ! Warning: The following connections close logic loops, and some paths !
  !          through these connections may not be analyzed.              !
  !                                                                      !
  ! Signal                            Driver            Load             !
  ! --------------------------------  ----------------  ---------------- !
  ! csum_2x16_temp<1>_cyo             LICE_X46Y82.COUT  SLICE_X46Y87.BX  !
   ----------------------------------------------------------------------
<\snip>


Article: 113474
Subject: Re: abel to vhdl converter
From: lingamaneni.naveen@gmail.com
Date: 14 Dec 2006 06:20:08 -0800
Links: << >>  << T >>  << A >>
Hello Guys,
First of all thanks for all of your valuble suggestions.I was able to
get the source code (ABEL) for all the PAL's now.Since most of the
PAL's were absolute now and for ROHS compliance we are redesigning the
board and now we want to replace bulky PAL's around 70 and eight XC3130
series(VHDL) into state of the art FPGA devices.

Coming to my first point
1. Can i have a VHDL main module and integrate all the individual .ABL
files as it is and achieve the same functionality of all the PAL's
within FPGA.
(With out converting ABEL to VHDL)

2. Here the board performance (timing of PAL) has to remain the same
with high speed FPGA also.Never worked on timing issues till now but
heard registering and using flip flop can solve problem any better
ideas?
(First i am working out on how to get the timing of a PAL from the old
board before knowing how to achieve the same timing with in a high
speed FPGA )

Sorry for my list of questions and Thanks for being supportive.

Naveen
lnaveen_2000@yahoo.com
lingamaneni.naveen@gmail.com

Gabor wrote:
> Paul wrote:
> > yea... if you've got the actual abel code, not just the "synthesized"
> > JED file, you're probably better off rewriting the VHDL.  I can't
> > imagine that anything that was originally written in ABEL is so
> > complicated that it'd take more than a couple hours to rewrite....  if
> > i'm not mistaken devices were pretty small back when folks where using
> > abel, so it can't feasibly be ALL that much logic to recode.
> >
> >
>
> This goes back a long time, but I remember that MachXL software
> from AMD used to be able to reconstruct source from a .JED file.
> This required a .JED that contained the symbol table (signal names)
> to end up with something readable.  It unfortunately showed your
> equations in sum-of-products just the way it went into the PAL,
> not the pre-compiled source.
>
> If you really have Abel code and not just the JEDEC file, it is my
> understanding that Xilinx still supports Abel for anything but top
> level code modules.  I still have designs using Abel in lower level
> modules, but those are supported with the older Foundation 4.1i
> tools, so I'm not sure you could use them in newer ISE projects.
> 
> HTH,
> Gabor




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