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 125675

Article: 125675
Subject: Re: Ping Jim: The PFD is dead!
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 31 Oct 2007 11:22:20 -0700
Links: << >>  << T >>  << A >>
Hi, John
I suppose you know about the old Xilinx app note:
http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf
which would benefit from your diode trick.
Cheers
Peter Alfke, Xilinx Applications

On Oct 31, 10:32 am, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Wed, 31 Oct 2007 09:38:41 -0700, r...@desinformation.de wrote:
> >> I "invented" this last week. FPGAs aren't very good at implementing
> >> the classic charge pump.
>
> >>http://s2.supload.com/free/PFD.jpg/view/
>
> >> The outputs here are just hard (not tri-state) logic outputs, driven
> >> directly by the up/down flipflops in the pfd circuit. It's nicely
> >> symmetric.
>
> >> John- Zitierten Text ausblenden -
>
> >> - Zitierten Text anzeigen -
>
> >But the Inventor mentioned the additional jitter due to uncorrelated
> >noise of the 2 PFD outputs and their summation in your example, and
> >the evil glitches due to unmatched symmetry and parasitic coupling of
> >the digital to the analog !
> >This must be worth a patent.
>
> >Having read
>
> >http://www.keystonesemiconductor.com/press_releases.html
>
> >i now fear the evil glitch and deadtime jitter to corrupt my computer
> >before global warming blasts icebergs and blazes glaciers.
>
> Oh, the guy is clearly a lunatic, and an amateur lunatic to boot. His
> writing is hilarious.
>
> But the dual-diode thing solves a couple of problems using an FPGA as
> a phase-frequency detector.
>
> John



Article: 125676
Subject: Re: Is it possible to debug a vhdl design over jtag?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 31 Oct 2007 12:30:50 -0700
Links: << >>  << T >>  << A >>
MM wrote:

> For the purpose of this discussion VHDL is a language describing hardware. 
> Every change in code requires new hardware to be synthesized. For this 
> simple reason software style debugging is not really possible with real 
> hardware. However, you can debug all you want (before going to hardware) 
> with VHDL simulators such as, for example, Modelsim, or Active HDL.

Good point.
Some prefer working out the logical problems
in a tight loop at the code level on a simulator.
This avoids waiting for a special place and route
on each try.

       -- Mike Treseler

Article: 125677
Subject: Re: FPGA vs ASIC
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 31 Oct 2007 13:11:54 -0700
Links: << >>  << T >>  << A >>
Thank you, Ray, for pointing this out.
We know that the carry delay is important, and we have used a few
tricks to make it short, while maintaining the appearance of a "ripple
delay".
Peter Alfke

On Oct 31, 10:26 am, Ray Andraka <r...@andraka.com> wrote:
> mk wrote:
> > Actually what the FPGAs has should be named "dedicated/hard-wired
> > carry ripple logic & routing" as there is not much "fast" about it.
> > What would've been fast is if they added some carry look ahead logic.
>
> Within a CLB, there certainly is carry look-ahead.  It is abstracted out
> in the user's guides as an implementation detail that is not visible to
> the user.  Be assured however, that there is a carry look-ahead going on
>   in the physical hardware.



Article: 125678
Subject: Re: Ping Jim: The PFD is dead!
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 01 Nov 2007 09:28:18 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Hi, John
> I suppose you know about the old Xilinx app note:
> http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf
> which would benefit from your diode trick.
> Cheers
> Peter Alfke, Xilinx Applications

The tristate drive is seen in many PFD's.
Tristate works well, but does float the FPGA pin
at the Opmap Bias point, and is also a noise-injection
point.
Also either the Diode, or Tristate directly couple
the FPGA Vcc and GND noise into the integrator (when ON)

So the "purists PFD", would use a TinyLogic analog Switch,
[example of 2 in one package : 74LVC2G66 ]
and keep the Hi-Z integrator node tiny, and shielded from
digital charge injection, and power supply noise.

Also, some designs have deliberate overlap in the PFD
impulses, as that avoids a dead-band, which can give
higher spurious noise spurs.

-jg


Article: 125679
Subject: Re: Capability of a FPGA device.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 01 Nov 2007 09:35:26 +1300
Links: << >>  << T >>  << A >>
MMJ wrote:

> Hi,
> 
> For a future project we are considering the use of FPGA technology and IP 
> cores instead of using an ASSP solution.
> As a software guy...only doing some initial invistigations I have absolutely 
> no specific idea of how much functionality you can expect to implement into 
> a FPGA device in the pricerange of maximum 100$.
> 
> Some of the basic functionality we need is:
> 
> - Control CPU (e.g. ARM9).
> - Memory Interface for control CPU and video decoder.
> - x number of I/O interfaces (High speed parrallel).
> - n Video decoders (MPEG2, MPEG4, H.264)
> - Interal switch matrix of some sort.
> 
> How much of this should we (hypothetical speaking) be able to implement in a 
> single device in the mentioned pricerange? Offcourse I don't expect an exact 
> answer to this question since everything depends on how each function is 
> realized. But a "This might be possible" or "Not in this world" answer with 
> some pointers would be very nice.  Hope this is not to stupid a question.

You should also look at the CODE and DATA size requirements, and the 
DATA bandwidths needed.

Also realise that the 'single chip' is rather a myth, you will need
the FPGA plus NV config and code storage plus run-time code storage.

Generally, if you can buy merchant silicon, that will always be cheaper
(both in use and R&D costs) than a FPGA solution - it also usually means 
you step to a smaller/cheaper FPGA.

For example, if your code/data will fit into a single chip 
microcontroller, you can eliminate many EMC issues.

-jg



Article: 125680
Subject: Re: Ping Jim: The PFD is dead!
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 31 Oct 2007 13:39:33 -0700
Links: << >>  << T >>  << A >>
On Wed, 31 Oct 2007 11:22:20 -0700, Peter Alfke <peter@xilinx.com>
wrote:

>Hi, John
>I suppose you know about the old Xilinx app note:
>http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf
>which would benefit from your diode trick.
>Cheers
>Peter Alfke, Xilinx Applications

The diode thing allows true overlap (ie, zero deadband operation)
without worrying about relative pfet/nfet drive strengths or tristate
enable times. It also eliminates a more subtle problem related to pin
capacitances, which would add yet another nonlinearity to the already
nonlinear xapp circuit.

Skyworks makes some 0.22 pF, SC79 schottkies that would be ideal here.

Loop gain doubles in the overlap region, but that's easy to deal with.
It's sure better than a flat spot.

The opamp situation can be interesting.

John



Article: 125681
Subject: Re: Ping Jim: The PFD is dead!
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 01 Nov 2007 10:28:10 +1300
Links: << >>  << T >>  << A >>
John Larkin wrote:

> On Wed, 31 Oct 2007 11:22:20 -0700, Peter Alfke <peter@xilinx.com>
> wrote:
> 
> 
>>Hi, John
>>I suppose you know about the old Xilinx app note:
>>http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf
>>which would benefit from your diode trick.
>>Cheers
>>Peter Alfke, Xilinx Applications
> 
> 
> The diode thing allows true overlap (ie, zero deadband operation)
> without worrying about relative pfet/nfet drive strengths or tristate
> enable times. It also eliminates a more subtle problem related to pin
> capacitances, which would add yet another nonlinearity to the already
> nonlinear xapp circuit.
> 
> Skyworks makes some 0.22 pF, SC79 schottkies that would be ideal here.
> 
> Loop gain doubles in the overlap region, but that's easy to deal with.
> It's sure better than a flat spot.

Yes, better systems take effort to avoid any dead-band

> 
> The opamp situation can be interesting.

With the single-resistor drawn in the Xilinx app note, it gets worse
- there is buffer contention during that (short) time = more unknowns

-jg


Article: 125682
Subject: Re: ERROR:Simulator:222 - Generated C++ compilation was unsuccessful
From: Alex Colvin <alexc@TheWorld.com>
Date: Wed, 31 Oct 2007 22:06:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
>THE ERROR:

>ERROR:Simulator:222 - Generated C++ compilation was unsuccessful

I've run into something like this fairly often. Usually because the 
[C++] compiler was unable to write the executable, because Windows thought 
it was busy.
There's a message about "unable to delete...", but it's usually lost in 
the shuffle.

If this is the case, kill any runaway simulation process. If the file 
remains busy, rename it. If that fails, pay your respects to Windows and 
reboot.

-- 
	mac the naïf

Article: 125683
Subject: Digilent V2P Board
From: "David Binnie" <td.binnie@blueyonder.co.uk>
Date: Wed, 31 Oct 2007 22:31:09 GMT
Links: << >>  << T >>  << A >>
Using the Digilent XUP V2P Board, I have to use additional memory (256 Mb 
DDR SDRAM).

The only memory drivers I can find run with the embedded processor kit.  I 
do not wish to use the PowerPC or Microblaze processor nor the EDK.  Does 
any one have access to some code to access the add on memory module 
directly.

tdb 



Article: 125684
Subject: Re: Ping Jim: The PFD is dead!
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 31 Oct 2007 15:47:42 -0700
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1193854940.231665.110490@z24g2000prh.googlegroups.com...
> Hi, John
> I suppose you know about the old Xilinx app note:
> http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf
> which would benefit from your diode trick.
> Cheers
> Peter Alfke, Xilinx Applications
>
Guys,
Beware of XAPP028...

From 
http://groups.google.com/groups/search?q=xapp028+symon+MAXSKEW+group%3Acomp.arch.fpga

Quote:-
    A small note of caution when using Peter's XAPP028 in Virtex II. As
well as constraining the logic to the CLBs shown in the app note, make
sure you specify a MAXSKEW attribute on the reference signal and
feedback signal to the circuit. I use 100ps. Without this the circuit
can occasionally malfunction depending on the place and route. (These
are the signals called 'from VCO divided by N' and 'from reference
frequency'.)
   There was no problem when this circuit was used on older FPGAs
where the routing to the F and G lookup tables in a single CLB was
guaranteed to have low skew. In Virtex II this is no longer the case
and a single signal that goes to both the F and G inputs of a CLB can
have significant skew if not constrained. This can cause the circuit
of XAPP28 to misbehave.

HTH., Syms. 



Article: 125685
Subject: Re: Capability of a FPGA device.
From: "evilkidder@googlemail.com" <evilkidder@googlemail.com>
Date: Wed, 31 Oct 2007 22:49:14 -0000
Links: << >>  << T >>  << A >>
>
> Some of the basic functionality we need is:
>
> - Control CPU (e.g. ARM9).
> - Memory Interface for control CPU and video decoder.
> - x number of I/O interfaces (High speed parrallel).
> - n Video decoders (MPEG2, MPEG4, H.264)
> - Interal switch matrix of some sort.


Can you share what sort of level of video decoding performance you
would need?  Would you need to support multiple video standards at the
same time?  What sort of I/O interfaces are needed - is it for the
video and if so what formats?  Is the CPU just required to control the
video decoder, or are there other tasks needed?

What you ask is not totally unfeasible depending on your precise
requirements.

Thanks,

Andy.


Article: 125686
Subject: Re: FPGA vs ASIC
From: mk <kal*@dspia.*comdelete>
Date: Wed, 31 Oct 2007 18:50:48 -0700
Links: << >>  << T >>  << A >>
On Wed, 31 Oct 2007 13:11:54 -0700, Peter Alfke <peter@xilinx.com>
wrote:

>Thank you, Ray, for pointing this out.
>We know that the carry delay is important, and we have used a few
>tricks to make it short, while maintaining the appearance of a "ripple
>delay".
>Peter Alfke
>
>On Oct 31, 10:26 am, Ray Andraka <r...@andraka.com> wrote:
>> mk wrote:
>> > Actually what the FPGAs has should be named "dedicated/hard-wired
>> > carry ripple logic & routing" as there is not much "fast" about it.
>> > What would've been fast is if they added some carry look ahead logic.
>>
>> Within a CLB, there certainly is carry look-ahead.  It is abstracted out
>> in the user's guides as an implementation detail that is not visible to
>> the user.  Be assured however, that there is a carry look-ahead going on
>>   in the physical hardware.
>

Peter,
If I remembering correctly there is a TTL IC which has a 4 bit CLA in
it. It would fit into the CLB nicely :-)

Article: 125687
Subject: Re: Ping Jim: The PFD is dead!
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 31 Oct 2007 20:20:59 -0700
Links: << >>  << T >>  << A >>
On Oct 31, 3:47 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> "Peter Alfke" <pe...@xilinx.com> wrote in message
>
> news:1193854940.231665.110490@z24g2000prh.googlegroups.com...> Hi, John
> > I suppose you know about the old Xilinx app note:
> >http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf
> > which would benefit from your diode trick.
> > Cheers
> > Peter Alfke, Xilinx Applications
>
> Guys,
> Beware of XAPP028...
>
> Fromhttp://groups.google.com/groups/search?q=xapp028+symon+MAXSKEW+group%...
>
> Quote:-
>     A small note of caution when using Peter's XAPP028 in Virtex II. As
> well as constraining the logic to the CLBs shown in the app note, make
Thanks, Syms, for pointing this out.
I published this in 1990, in the XC3000 era, and I was proud of
packing it so nicely.
Your comment makes me retire the circuit, but it will unfortunately
survive on the internat...
Peter

> sure you specify a MAXSKEW attribute on the reference signal and
> feedback signal to the circuit. I use 100ps. Without this the circuit
> can occasionally malfunction depending on the place and route. (These
> are the signals called 'from VCO divided by N' and 'from reference
> frequency'.)
>    There was no problem when this circuit was used on older FPGAs
> where the routing to the F and G lookup tables in a single CLB was
> guaranteed to have low skew. In Virtex II this is no longer the case
> and a single signal that goes to both the F and G inputs of a CLB can
> have significant skew if not constrained. This can cause the circuit
> of XAPP28 to misbehave.
>
> HTH., Syms.



Article: 125688
Subject: Re: FPGA vs ASIC
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 31 Oct 2007 21:19:13 -0700
Links: << >>  << T >>  << A >>
On Oct 31, 6:50 pm, mk <kal*@dspia.*comdelete> wrote:
>
> Peter,
> If I remembering correctly there is a TTL IC which has a 4 bit CLA in
> it. It would fit into the CLB nicely :-)

Do you think of the 74181 (=9341 in Fairchild parlance)? Nostalgia
from 1970...
It's a 4-bit ALU, but that means 22 signal pins in a 24-pin package:
4+4 operand inputs and 4 result outputs,5 mode controls (one of them
to change between logic and arithmetic), carry in, carry out, carry
generate, and carry propagate, plus an A=B output thrown in for free.
Hard to put into a CLB, unless you define the mode by configuration.
Peter



Article: 125689
Subject: Re: FPGA vs ASIC
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 01 Nov 2007 04:42:24 GMT
Links: << >>  << T >>  << A >>
mk wrote:
> 
> Peter,
> If I remembering correctly there is a TTL IC which has a 4 bit CLA in
> it. It would fit into the CLB nicely :-)

That reminds me of the time I was in one of two row boats racing to 
shore.  I thought I could "help" the race by jumping out and pushing the 
boat with my swimming.  Boy did we suddenly slow down!

A 4-bit CLA in a CLB (wait - is there a CLK?  no, no...) is marginally 
helpful in only the most extreme cases.  Very long adders would still 
need a "generate" signal from each segment in a multi-segment adder 
(even the 74181 is a 4-bit ALU) when the individual sum is all-1s to go 
along with the carry from the carry chain.  If you wait for the result 
to decode the generate, you need to get on and off the carry chain and 
through two levels of logic to detect a 16-bit "generate" or double your 
counters with A+B and A+B+1 results to come up with a C and G at the 
same time.  What's this gaining?  The carry from your 4-bit CLA needs 2 
levels of logic to generate the "lookahead" from the 4 segments.  A 64 
bit counter would need 4 levels of logic plus routing *or* twice the 
number of adders with 2 levels of logic on top of routing.  This is a 
quick way to make things go very slow.

If you want to accelerate small adders in FPGAs, you can't do it with 
FPGA logic.  The carry chains are already very low propagation though 
there might be an opportunity to get on and off the carry chains more 
quickly with focused silicon development, perhaps compromising other 
performance aspects of the chip to achieve that improved on/off adder delay.

If you want to accelerate very large adders, there are methods that can 
provide better results than a CLA.  You know about carry select, carry 
skip, etc, you should know that for small adders there's no help in the 
FPGA.

Don't believe me?  Take a splash.  Watch the boat slow down.  Synthesis 
is cheap!  Or was the smiley face showing an attempt at humor that I 
just can't grasp?

If you're suggesting that adding dedicated CLA functionality to the FPGA 
fabric, think of what it takes to produce the generate with the carry 
and aggregate the signals into the CLA structure.  Do you think it could 
possibly be worth it for 99% of the adders in user designs?

- John_H

Article: 125690
Subject: Re: FPGA vs ASIC
From: mk <kal*@dspia.*comdelete>
Date: Thu, 01 Nov 2007 06:26:54 GMT
Links: << >>  << T >>  << A >>
On Wed, 31 Oct 2007 21:19:13 -0700, Peter Alfke <alfke@sbcglobal.net>
wrote:

>On Oct 31, 6:50 pm, mk <kal*@dspia.*comdelete> wrote:
>>
>> Peter,
>> If I remembering correctly there is a TTL IC which has a 4 bit CLA in
>> it. It would fit into the CLB nicely :-)
>
>Do you think of the 74181 (=9341 in Fairchild parlance)? Nostalgia
>from 1970...
>It's a 4-bit ALU, but that means 22 signal pins in a 24-pin package:
>4+4 operand inputs and 4 result outputs,5 mode controls (one of them
>to change between logic and arithmetic), carry in, carry out, carry
>generate, and carry propagate, plus an A=B output thrown in for free.
>Hard to put into a CLB, unless you define the mode by configuration.
>Peter
>

Actually I was thinking of 74182. The resemblance between it and page
193 is quite interesting, no? 4 pairs of inputs in addition to carry
from previous block. The outputs need changing a little though.

Article: 125691
Subject: Re: IDE to Flash memory
From: Franck <franck.jullien@gmail.com>
Date: Thu, 01 Nov 2007 07:55:29 -0000
Links: << >>  << T >>  << A >>
On Oct 31, 11:42 am, Antti <Antti.Luk...@googlemail.com> wrote:
> On 31 Okt., 07:57, Franck <franck.jull...@gmail.com> wrote:
>
> > Thanks,
>
> > I have seen this product but this is not flexible enough for me. This
> > king of chip is too specific, that why I wanted to do this with a
> > fpga. I don't know exactly how flash memory works so I'm not able to
> > know which throughput I could reach with an IDE interface and a flash
> > memory controller in a fpga....
>
> > I thought someone else could have done this before, then I would gain
> > some time...
>
> > Anyway, I'll have to shearch by myself :)
>
> you are asking for "commercial grade" IP core.
> I have done evalution/search for similar case, the closest you get
> are partial IP solutions for around 20.000 USD or so for the ATAPI
> device IP core.
>
> I bet you will find it not free what you are looking for
>
> Antti

Thanks Antti,

I think I'm going to have to study ATA standard and flash memory
mechanism :)

Regards,
Franck.


Article: 125692
Subject: can i use dual edge or two clocks?
From: raullim7@hotmail.com
Date: Thu, 01 Nov 2007 01:04:49 -0700
Links: << >>  << T >>  << A >>
My FPGA master clock is at 100MHz. I have assigned a counter to count
from 0 to 99 to achieve a period of 1usec. As the counter is counting
from 0 to 99, i will take 1 sample at each count and therefore i have
a total of 100 samples. Now my task requires me to increase my sample
size to 200. However, i can't increase the counter count to 0 - 200 as
this will increase the period to 2usec. My task requires me to double
the sample size while maintaing the period at 1usec.

I tried to implement this by adding another clock to the system but i
am not able to synthesis the code as one clock is only allowed same
for dual edge behavior of the clock pulse. I am running out of ideas
how to accomplish this task as i am not very strong in VHDL coding and
my deadline is nearing. Would appreciate if someone can help me.
Thanks!!


Article: 125693
Subject: Re: can i use dual edge or two clocks?
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 1 Nov 2007 09:24:23 +0100
Links: << >>  << T >>  << A >>
raullim7@hotmail.com wrote:

> My FPGA master clock is at 100MHz. I have assigned a counter to count
> from 0 to 99 to achieve a period of 1usec. As the counter is counting
> from 0 to 99, i will take 1 sample at each count and therefore i have
> a total of 100 samples. Now my task requires me to increase my sample
> size to 200. However, i can't increase the counter count to 0 - 200 as
> this will increase the period to 2usec. My task requires me to double
> the sample size while maintaing the period at 1usec.

Use a PLL to double the clock frequency, if your FPGA has one.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 125694
Subject: Re: xilinx bmm file problem
From: Arnim <clv.5.minral@spamgourmet.com>
Date: Thu, 01 Nov 2007 10:46:24 +0100
Links: << >>  << T >>  << A >>

> Has anybody experience with xilinx bitfile merging using a bmm file?
[...]
> The new bitfile is generated, but no luck. Program not running. 
> Anybody an idea how to tackle this?

I once summarized my experience with bmm files in
  http://home.mnet-online.de/al/BRAM_Bitstreams.html

Maybe you find some answers there.

Cheers

Arnim

Article: 125695
Subject: Re: can i use dual edge or two clocks?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Thu, 01 Nov 2007 19:10:33 +0800
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> raullim7@hotmail.com wrote:
> 
>> My FPGA master clock is at 100MHz. I have assigned a counter to count
>> from 0 to 99 to achieve a period of 1usec. As the counter is counting
>> from 0 to 99, i will take 1 sample at each count and therefore i have
>> a total of 100 samples. Now my task requires me to increase my sample
>> size to 200. However, i can't increase the counter count to 0 - 200 as
>> this will increase the period to 2usec. My task requires me to double
>> the sample size while maintaing the period at 1usec.
> 
> Use a PLL to double the clock frequency, if your FPGA has one.
> 
Or a DDR input cell (assuming your FPGA has them), or even two
flipflops, one positive-edge triggered and one negative. Of course, this
assumes your 100MHz clock is of good enough quality, ie closely symmetric.

Article: 125696
Subject: Re: Capability of a FPGA device.
From: "MMJ" <Spam@aldrig.com>
Date: Thu, 1 Nov 2007 12:16:14 +0100
Links: << >>  << T >>  << A >>
> attempt to use ARM9 soft ip in FPGA below 100$ is bad idea, depending
> on your yearly volume maybe it could be possible to fit the CPU itself
> but not much more, and performance would be very bad anyway.

> if you dream adding ARM9 + something else + n>0 video decoders into
> sub 100$ FPGA hm you need wait a few years... or some more years for
> 35nm FPGA's

> so you need really re-thing what parts of the system you want into the
> FPGA and what not

Thank you for replying!

Ok.....what if I change the softcore ARM9 to something else...like 
MicroBlaze and maybe limit the video decoders to 4 ?

--
MMJ




Article: 125697
Subject: Re: Capability of a FPGA device.
From: csantos <cayetanosantos@gmail.com>
Date: Thu, 01 Nov 2007 11:50:57 -0000
Links: << >>  << T >>  << A >>
Hi,

why don't you have a look at actel's Igloo family? http://www.actel.com/products/IGLOO/
Recently they added support for the ARM cortex core, with plently of
other interesting capabilities.

csb

On 31 oct, 16:03, "MMJ" <S...@aldrig.com> wrote:
> Hi,
>
> For a future project we are considering the use of FPGA technology and IP
> cores instead of using an ASSP solution.
> As a software guy...only doing some initial invistigations I have absolutely
> no specific idea of how much functionality you can expect to implement into
> a FPGA device in the pricerange of maximum 100$.
>
> Some of the basic functionality we need is:
>
> - Control CPU (e.g. ARM9).
> - Memory Interface for control CPU and video decoder.
> - x number of I/O interfaces (High speed parrallel).
> - n Video decoders (MPEG2, MPEG4, H.264)
> - Interal switch matrix of some sort.
>
> How much of this should we (hypothetical speaking) be able to implement in a
> single device in the mentioned pricerange? Offcourse I don't expect an exact
> answer to this question since everything depends on how each function is
> realized. But a "This might be possible" or "Not in this world" answer with
> some pointers would be very nice.  Hope this is not to stupid a question.
>
> Best Regards
>
> --
> MMJ



Article: 125698
Subject: Re: 2 FPGAs /w programming FLASH in one JTAG chain
From: "Toni Merwec" <mistertorpedo@freenet.de>
Date: Thu, 1 Nov 2007 13:23:33 +0100
Links: << >>  << T >>  << A >>
"Patrick Dubois" <prdubois@gmail.com> schrieb im Newsbeitrag 
news:1193673009.082475.114600@k35g2000prh.googlegroups.com...
>
> The two proms can be considered as one big prom twice as large. No
> prom is exclusively dedicated to one FPGA in particular. For example,
> the bit file for FPGA #1 might take 2/3 of the first prom and the bit
> file for FPGA #2 might be half in prom #1 and half in prom #2. This is
> handled for you when you create your mcs files for the proms.
>

Okay, thank you very much. But one more question: What about the DO pins 
from the PROMs to the FPGA? In the Platform Flash In-System Programmable 
Configuration PROMs data sheet ds123.pdf (page 18) it is recommended to tie 
the DO outputs of both PROMs together and connect the FPGAs in series. I 
don't see any reason to do it this way. What I would have done normally 
(without having read the user guide) is having the DO of one PROM connected 
to one FPGA (DIN) and the other DO of the second PROM to the the other DIN 
of the remaining FPGA. What is the reason not to do so, i.e. is there any 
reason? Any help is highly appreciated!

Regards

Toni 



Article: 125699
Subject: Re: HELP, how to time constraint part of a design?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 01 Nov 2007 13:22:26 +0000
Links: << >>  << T >>  << A >>
On Wed, 31 Oct 2007 14:24:38 -0000, llombard@gmail.com wrote:


>Indeed, for now it's ok, but I had to cut the formula into pieces with
>a counter to be able to meet timing requirement. The price to pay is
>that the formula is no more computed into 1 clock cycle but into 2 or
>more cycles with an added counter.

This sounds like adding pipeline stages.

>The reason why I forst wondered about this problem is because at first
>the loop worked sometimes and would have weird behaviour when changing
>almost insignificant parts of the code. For example, some integer
>comparisions were wrong. I then realized that even if the ISE "place
>and rout report" said that the 50MHz timing constraint "TS_clk =
>PERIOD TIMEGRP "clk" 20 ns HIGH 50%" was always met, the ISE
>"Synthesis report" would say "maximum frequecy: 20MHz" but without
>issuing any error (do they check different things?). 

The ISE synthesis report gives an estimate of the maximum frequency, a
prediction of what PAR might do, but not an accurate figure. I have
often found it 10% or more out. But never as far off as 20MHz instead of
50 MHz... If it's that far off you were correct that you had to fix your
code.

The PAR report contains the accurate figure, and the .twr trace report
contains more detail about which paths were too slow.

>> If you want to run it faster, add more pipeline registers around the
>> multiplier and re-simulate to verify that your control loop stability is
>> satisfactory. (Adding delays around a feedback loop makes me nervous :-)
>
>What does "add more pipeline registers" mean? does it mean cutting
>even more into pieces? Then I still have the "number of cycles price"
>to pay? 

It does increase the number of cycles latency, but you can start a new
computation each cycle, so throughput is high. Of course, for a control
loop, latency is probably important; that's why you need to simulate to
check stability if you add latency.

>Do you know another cheap kit with several ADC/DAC with
>"parralel access" or do I have to take a standard dev. kit and add a
>custom AD/DA daughter card

http://www.enterpoint.co.uk/moelbryn/raggedstone1.html
and
http://www.enterpoint.co.uk/moelbryn/modules/adc_ad9727.html
may be of interest

- Brian



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