Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
> To get 12 bits with a Bit-serial integrator, at 20MSPS, gives > a virtual clock of 20 x 4096, or 81GHz (!). > Also, consider jitter of 100ps -> one part in 500, or appx 9 bits, > so you need 10ps region for 12 bits. > > Other ADC topologies are Successive approximation, and FLASH. > Both use high performance comparitor(s), and increasing component > precision, to give better numbers at lower clock rates. > > FPGAs have no precision analog numbers, so you will need external > analog blocks to achieve 20Msps > > There may be scope for using some simple analog precision > ( eg 1% resistors, multiple outputs ) to simplify SD-ADCs, > ( just as they can simplify DACs ), but I have not seen > info on this. > > viz For a DAC, you can use two 6 bit DACS, and a 64:1 summing junction > ( two good tolerance resistors ), to give 12 bit DAC, but with 6 bit > clock rates. > DPLLs in FPGAs could give interesting scope for finer time-definition. Hi Jim, I'm interested the solution of DAC with divided adders code and summing resistors. Have you some sources of the converter? Regards Janusz RaniszewskiArticle: 47876
I designed FPGAs once upon a time, and the majority of the power was taken up by: a) the flops and clock tree b) the large drivers out onto the bus routing network I used spice to determine this, and verified it by measuring power consumption of hand built bitstreams. The LUTs and local logic are really too small in drive value into too small a capacitance to really mean much in terms of power consumption. My gut says, keep the number of flops*toggle rate at a minimum. Keep the circuits as small as possible, and floorplan the logic blocks to keep the routes down. I wouldn't worry too much about the rest. Bob If you're still over power budget, then you may need Ray's advice. "Ray Andraka" <ray@andraka.com> wrote in message news:3D9EE675.D82A8BFA@andraka.com... > I sort of alluded to that. In an FPGA it is even more true, as the routes > also consume power. I like the shift register (bar graph) type machines > because they minimize the logic leading into each state since the next state > only needs an equation for set, not for reset. Unfortunately, they are a bit > more obtuse to code and the synthesizers generally don't have them as an option > style. They also are convenient for the SRL16 primitives. > > Helmut Sennewald wrote: > > > "Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag > > news:3D9D7554.9FD02FC8@andraka.com... > > > A one-hot is pretty much minimal power for a decoded state machine. All > > the > > > bits in a state machine necessarily have to have an even number of > > transitions > > > in a complete cycle of the state machine. The one-hot puts both > > transitions in > > > adjacent states. We've used a shft register style state machine where > > '1's get > > > shifted in. Sort of like a sticky one-hot. While this reduces the number > > of > > > input terms to each flip-flop, it only postpones the 1 to 0 transition to > > the > > > end of the cycle. A grey coded machine is an encoded machine. It has > > fewer > > > transitions (one per state instead of two) and less flip-flops so its > > power is > > > less. Be aware that any gains in the state machine might be lost in the > > state > > > decode, especially if there are not many 'hidden' states. A grey coded > > machine > > > becomes difficult to design with many branches unless extra filler states > > are > > > added, since every loop in the state diagram must have an even number of > > states. > > > > > > > Hello Ray, > > I have read here a lot about the power savings in the area of > > the flipflops used in the state machine, but all have forgotten > > that there is a lot of logic around the state flipflops which also > > change its level. Normally there are lots of AND and OR gates > > feeding the state flipflops. Especially the gray coder could > > dissipate more power than the less changing flipflops will save. > > Have anybody really measured any numbers in a real circuit? > > > > Best Regards > > Helmut > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 47877
Janusz Raniszewski wrote:
>
<snip>
> > viz For a DAC, you can use two 6 bit DACS, and a 64:1 summing junction
> > ( two good tolerance resistors ), to give 12 bit DAC, but with 6 bit
> > clock rates.
> > DPLLs in FPGAs could give interesting scope for finer time-definition.
>
> Hi Jim,
> I'm interested the solution of DAC with divided adders code and summing resistors.
> Have you some sources of the converter?
We use rate multiplier, or what I prefer to call Picket Fence DACs.
These code better than PWM DACs, and have higher freq content, more
easily
filtered.
This BOOLEAN EQN code uses a single 6 bit counter, and creates two DAC
streams,
that are then analog mixed 64:1.
By using some ( but not too expensive ) analog precision, you can
increase
the LSb freq content significantly.
hth - jg
/* ============= Toggle FF Counters synth using D, if T unvail
=========== */
RMCtr0.d = !RMCtr0; /* LSB toggles ALL others count Up */
RMCtr1.d = !RMCtr1 & RMCtr0 /* build TOGGLE flipflops */
#RMCtr1 & !RMCtr0;
RMCtr2.d = !RMCtr2 & RMCtr1 & RMCtr0 /* toggle @ x11, else hold ,
etc */
# RMCtr2 & !(RMCtr1 & RMCtr0);
RMCtr3.d = !RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0
#RMCtr3 & !(RMCtr2 & RMCtr1 & RMCtr0);
RMCtr4.d = !RMCtr4 & RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0
# RMCtr4 & !(RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0);
RMCtr5.d = !RMCtr5 & RMCtr4 & RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0
#RMCtr5 & !(RMCtr4 & RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0);
/* ---- Picket fence, or Rate Multiplier DAC ------- */
/* Define the 'pickets' - sum as 0..63 */
Bit5 = !RMCtr0; /* 32 Pulses, ODD.Even */
Bit4 = !RMCtr1 & RMCtr0; /* 16 Pulses, etc */
Bit3 = !RMCtr2 & RMCtr1 & RMCtr0; /* 8 */
Bit2 = !RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0; /* 4 */
Bit1 = !RMCtr4 & RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0; /* 2 */
Bit0 = !RMCtr5 & RMCtr4 & RMCtr3 & RMCtr2 & RMCtr1 & RMCtr0; /* 1 */
/* Collect the pickets, weighted with DACip bits */
RM_OUT_MSR.d = Bit5 & DACip11
# Bit4 & DACip10
# Bit3 & DACip9
# Bit2 & DACip8
# Bit1 & DACip7
# Bit0 & DACip6;
RM_OUT_LSR.d = Bit5 & DACip5
# Bit4 & DACip4
# Bit3 & DACip3
# Bit2 & DACip2
# Bit1 & DACip1
# Bit0 & DACip0;
/* MIX/SUM these to DAC outputs, using 64:1 weighted resistors,
( eg 10K / 640K ) better than 1%
RM_OUT_MSR ---- 10K -----+-----+-- R ----+--> DC
| | |
RM_OUT_LSR ---- 640K ----+ === ===
| |
GND GND
Notes/Tips : this should be registered, not combin, as you want absolute
smallest
jitter and no glitches.
For highest performance, feed the digital OP thru a TinyLogic buffer
gate,
as then the DAC Vcc/Gnd can be clean and stable
In SPLD/CPLD, commonly Voh is neither strong nor clean
*/
Article: 47878
There are a number of high current things in the FPGA. First, the static current is relatively
high. The clock tree dissipates quite a bit of power because unlike an ASIC it goes to every
CLB (columns can be turned off in some devices). Data transitions, however, are the Lion's
share of the power dissipation. This can be demonstrated by observing the power when the clock
is running but the design is held in an idle state (no data moving through it) and when it is no
longer idle. In designs with high clock rates, the current change can be 10x or more.
Actually, an interesting paper last year at FPGA claims that a large percentage of that power is
due to the combinatorial glitching after the clock edge. In the FPGA, that can lead to a large
number of nodes switching several times per clock cycle, especially where there are multiple
levels of logic between flip-flops. That is aggrabated by long routes on those paths as well,
since the routes in an FPGA include active switches. The degree of that intra-clock switching
is obviously design dependent. What it does say is that keeping logic levels to a minimum
(deeper pipelining), and floorplanning to all routing as short as practical are important to
reducing power.
I have seen a pretty consistent power savings of around 20% achieved by floorplanning, which
seems to confirm the findings in the paper that power dissipation in the routing is a
significant part of the overall power. Most of our designs already have just a single level of
logic between flip-flops (we do that for performance and for floorplanning reasons), so I can't
really collaborate that finding. The bottom line is that the same techiques used to achieve
maximum performance also reduce power consumption.
malgi wrote:
> I designed FPGAs once upon a time, and the majority of the power was taken up by:
>
> a) the flops and clock tree
> b) the large drivers out onto the bus routing network
>
> I used spice to determine this, and verified it by measuring power consumption of
> hand built bitstreams.
>
> The LUTs and local logic are really too small in drive value into too small a capacitance
> to really mean much in terms of power consumption.
>
> My gut says, keep the number of flops*toggle rate at a minimum. Keep the circuits as
> small as possible, and floorplan the logic blocks to keep the routes down. I wouldn't worry
> too much about the rest.
>
> Bob
>
> If you're still over power budget, then you may need Ray's advice.
>
> "Ray Andraka" <ray@andraka.com> wrote in message news:3D9EE675.D82A8BFA@andraka.com...
> > I sort of alluded to that. In an FPGA it is even more true, as the routes
> > also consume power. I like the shift register (bar graph) type machines
> > because they minimize the logic leading into each state since the next state
> > only needs an equation for set, not for reset. Unfortunately, they are a bit
> > more obtuse to code and the synthesizers generally don't have them as an option
> > style. They also are convenient for the SRL16 primitives.
> >
> > Helmut Sennewald wrote:
> >
> > > "Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag
> > > news:3D9D7554.9FD02FC8@andraka.com...
> > > > A one-hot is pretty much minimal power for a decoded state machine. All
> > > the
> > > > bits in a state machine necessarily have to have an even number of
> > > transitions
> > > > in a complete cycle of the state machine. The one-hot puts both
> > > transitions in
> > > > adjacent states. We've used a shft register style state machine where
> > > '1's get
> > > > shifted in. Sort of like a sticky one-hot. While this reduces the number
> > > of
> > > > input terms to each flip-flop, it only postpones the 1 to 0 transition to
> > > the
> > > > end of the cycle. A grey coded machine is an encoded machine. It has
> > > fewer
> > > > transitions (one per state instead of two) and less flip-flops so its
> > > power is
> > > > less. Be aware that any gains in the state machine might be lost in the
> > > state
> > > > decode, especially if there are not many 'hidden' states. A grey coded
> > > machine
> > > > becomes difficult to design with many branches unless extra filler states
> > > are
> > > > added, since every loop in the state diagram must have an even number of
> > > states.
> > > >
> > >
> > > Hello Ray,
> > > I have read here a lot about the power savings in the area of
> > > the flipflops used in the state machine, but all have forgotten
> > > that there is a lot of logic around the state flipflops which also
> > > change its level. Normally there are lots of AND and OR gates
> > > feeding the state flipflops. Especially the gray coder could
> > > dissipate more power than the less changing flipflops will save.
> > > Have anybody really measured any numbers in a real circuit?
> > >
> > > Best Regards
> > > Helmut
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 47879
Meeting or beating performance targets doesn't say much. If you set the
performance/density bar low enough, even the most naive approaches will easily
beat the target. The real question is whether you are using the device anywhere
near its capability. As for comparisons, you need to be careful what you are
comparing it to. There is an astonishing amount of mediocre or worse design
going on out there. The fact that the average FPGA user only does one FPGA
every 18-24 months and the tools/devices are changed at a much faster rate than
that alone says that a large number of the FPGA designs are being done as
someone is learning the tools and device, and therefore most likely not making
very good use of it. Pick one of those designs as your comparison metric, and
again you will look pretty good, especially if the designer using your tool has
more experience with the tools and devices.
As I said, there is a place for such tools, but for the most part, it is
probably not appropriate for something where cost, power or density is an
issue. What tools like this do is lower the bar to make it more accessible for
those without the expertise. It is not a replacement for the expertise, just a
tool that lowers the bar somewhat. My experience with many of the high level
tools has been any time savings afforded has been far overshadowed by the
"pushing on a rope" that is often needed to get the tool to do what you know is
right. Synthesis allows you to get around that where needed. Does this tool
also allow it? Some of the other HLL tools do not, so they become very awkward
to make work when you are pushing into the corners of the envelope.
Brett Cline wrote:
> Hi Ray,
> Sorry for the delay in my response, I'm traveling a bunch these days.
>
> Healthy skeptisim is great. I was actually skeptical when I started
> working on this technology about 3 years ago.
> Regarding your question on performance. In every case so far, we met or
> beat the performance targets for the device. In most cases we will beat area
> as well, but not all. The reason is that the compiler will do things (like
> share resources) that you simply will not because of the complexity of
> trying to manage it.
> I don't advocate using Handle-C. Everything I've seen as well brings it
> too close to hardware. For an algorithmic design, I want to leave my
> algorithm untouched. And to leave the algorithm untouched you must have, as
> someone pointed out, a very sophisticated compiler. We've already done
> designs such as image compression, encryption, filters, etc. where we've
> been able to create multiple RTL implementations with different
> area/performance tradeoffs in a fraction of the time it took to create a
> single version of the hardware by hand. And, in most cases, we were able to
> get a final end results (area vs. performance) than the customer got by
> hand. You'll say the same thing they did: "No Way!" -- that's ok, it's up to
> us to prove it.
>
> This is simply a progression in hardware design much as a C compiler was
> a progression beyond assembly in software. Yes, there will always cases
> where the HDL has to be so compact to meet the goals that you must write low
> level verilog (or even gates). As president of your company, I'm sure you
> would agree for certain applications, the value of time to market
> dramatically overshadows most other costs in the process. Clearly the design
> must meet timing - clearly it must be in some tolerance of area -- but if
> you can save 3,6, or more months to market -- what is the savings (or gain)
> there?
>
> For the "Show Me" part, let's talk about that - the proof is in real
> results.
>
> Thanks for the spirited discussion -
> Brett
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3D9A76DD.453A4B46@andraka.com...
> >
> >
> > Brett Cline wrote:
> >
> > > Hi All-
> > >
> > > Synthesis from a C/C++ algorithm is absolutely possible and has been
> in
> > > use for some time. Even "plain vanilla C" algorithms can be used with
> the
> > > right synthesis product.
> >
> > Show me. Nothing I've seen can handle C code that was not specifically
> written
> > to create hardware. I think your next sentence probably validates that as
> > well. Plain vanilla C has nothing in it to support concurrency, and I
> know of
> > no product that can infer that concurrency from existing (not written
> > specifically to map to hardware, usually using special extensions) code.
> >
> >
> > > Obviously it does take some amount of hardware
> > > knowledge to get reasonable hardware out the backend. All that should be
> > > required is to add the hardware interface structure to the C/C++
> algorithm.
> > > For that we recommend using SystemC (there is a reference implementation
> > > available under an open source license at www.SystemC.org). SystemC
> provides
> > > the necessary abstraction in C++ to add concurrency, bit accuracy, and
> other
> > > hardware-isms to the C/C++ algorithm.
> > >
> > > To take the algorithm to hardware (RTL Verilog or VHDL) my company
> offers
> > > a product called "Cynthesizer" for high-level synthesis from SystemC.
> We've
> > > had a number of customers take generic algorithms (some even from the
> web)
> > > such as filters, encryption, multimedia, etc. and convert them directly
> to
> > > RTL Verilog and VHDL. The resulting RTL can be put into any FPGA or ASIC
> > > synthesis tool as well as any other tool that operates on RTL.
> >
> > But at what price? Is the performance and density reasonably close to a
> what a
> > skilled hardware designer can accomplish?
> >
> > >
> > >
> > > For more information check out our web site at www.ForteDS.com or feel
> free
> > > to email me directly.
> > >
> > > Best regards,
> > > Brett
> > >
> > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > news:3D894809.ECF33E30@andraka.com...
> > > > Not exactly. There are several vendors that have C to hardware
> > > compilers,
> > > > but don't expect to take plain vanilla C and compile it directly to
> > > hardware.
> > > > For the most part, these tools use subsets and extensions to C to
> permit
> > > > description of hardware and all the parallelism that implies in a
> C-like
> > > > environment. It raises the level of abstraction, and as a result you
> tend
> > > to
> > > > get a design that is more bloated and slower than one done closer to
> the
> > > > hardware. The point is that there is no free lunch, there is a
> > > considerable
> > > > engineering effort to convert your software to something that will run
> at
> > > a
> > > > reasonable speed in an FPGA that you can afford to buy.
> > > >
> > > > mike wrote:
> > > >
> > > > > I can't claim to be an expert, but what I think you want to do isn't
> > > > > going to work. You can't take any arbitrary C/C++ program and
> convert
> > > it
> > > > > into VHDL code that will run on an FPGA. For making something like
> a
> > > > > hardware mp3 player, you may want to look at something like a
> > > > > programmable DSP board. Also, you should check on what, if any,
> analog
> > > > > outputs are avilable from the FPGA you're using. For example, on
> the
> > > > > Altera student board, the only analog output is for a VGA monitor,
> so if
> > > > > you wanted to make an mp3 player using one you'd need to build an
> > > > > interface to convert the decoded digital audio into analog audio.
> > > > > Mike
> > > > >
> > > > > On Tue, 17 Sep 2002 09:27:21 +0000, DJohn wrote:
> > > > >
> > > > > > Hi all VHDL experts,
> > > > > > Is there any tools which can convert a C\C++ source file to VHDL
> .
> > > For
> > > > > > example If I have a C source code for a MP3 decoder , Can any tool
> can
> > > > > > convert it into VHDL equivalent. There is some facility in FPGA
> > > > > > Advantage to generate a wrapper VHDL for a C File , what exactly
> is
> > > > > > that ? Does that mean I can synthesize a C\C++ file by creating a
> VHDL
> > > > > > Wrapper. Please help
> > > >
> > > > --
> > > > --Ray Andraka, P.E.
> > > > President, the Andraka Consulting Group, Inc.
> > > > 401/884-7930 Fax 401/884-7950
> > > > email ray@andraka.com
> > > > http://www.andraka.com
> > > >
> > > > "They that give up essential liberty to obtain a little
> > > > temporary safety deserve neither liberty nor safety."
> > > > -Benjamin Franklin, 1759
> > > >
> > > >
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 47880Hi, I get numerous hold time violations when I run my design thru a simulation in the Quartus II tool. I dont get any such messages during compilation. But when I run a simulation, I get these errors. Also, these errors have started appearing after I used a pll and divided the circuit clock into half of the on-board clock. I did not design the pll but is used from the ones provided in the Apex 20KE device. The hold time violation are all on one specific register, which I can't find in my design. Does anyone have any ideas, how can I fix the problem. Thanks, PrashantArticle: 47881
hi all, all ic manufacturers says that there IC is made of some .13 micron or .18 micron technology. what exactly this dimension correspond to ?Article: 47882
Hi Tony,
This is probably not the answer you want, but...
See if you can find a copy of version 4.1.
I have not heard any good things about version 5 yet. My big worry
stems from the service pack arriving before the product.
SH7
On Sun, 06 Oct 2002 01:51:01 GMT, "Tony M" <tonym_98@hotmail.com>
wrote:
>Hey all...
>
>In the past I've used ActiveHDL (great product!) But this semester I had a
>tighter budget so I'm giving the Xilinx WebPack ISE 5.1i + Service Pack 1 a
>try.
>
>I have a XC95108 CPLD next to my Virtex chip and need to download some
>simple VHDL to the CPLD... but ISE won't Fit the code...
>
>here's the error I get:
>Started process "Fit".
>
>can't read "xcpldFitDesFastConnectUIM": no such variable
> while executing
>"if { !$xcpldFitDesFastConnectUIM } {
> lappend Options "-nouim"
> }"
> invoked from within
>"if { [string equal $p_DevFamily xc9500] } {
> if { !$xcpldFitDesFastConnectUIM } {
> lappend Options "-nouim"
> }
> switch -- $xcpldFitDesLocal..."
> (file "C:/Xilinx/data/projnav/scripts/_cpldfitrun.tcl" line 95)
>
>Now... I disabled the FastConnect optimization routine in the options and it
>still gives that error. What can I do? I'm not familiar enough yet with
>ISE to figure this out on my own!
>
>Thanks,
>Tony
>
Article: 47883In article <3da045a3$0$22176$afc38c87@news.optusnet.com.au>, <hamish@cloud.net.au> wrote: >Phil Tomson <ptkwt@shell1.aracnet.com> wrote: > >> However, Tcl has been around for a while so there tend to be a lot of >> folks who know it and it's easy to embed Tcl in applications written in >> C/C++. I suspect that it's the latter reason that Tcl is used in >> ModelSim and several other EDA apps. > >I'm quite a fan of Perl. IMHO every VHDL or Verilog developer could >benefit from a basic knowledge of Perl and particularly its regular >expressions. I could say the same about Ruby.... And Ruby's regular expressions are are quite similar to Perl's with one exception: Ruby's regular expressions are actually objects which can be manipulated as objects whereas Perl's aren't. >And Tcl as well, because so many of the tools have >integrated Tcl (ModelSim, Synplify, ...) > >It might be that Perl wouldn't make a very good interactive shell >though. Perl certainly has its share of haters, most of whom are Python >users now I think. Well, I wouldn't put myself in the Perl-hating class, I guess I'd say I'm a reformed Perl programmer. I programmed in Perl for six or seven years and even did object oriented Perl - actually, that's when I decided there must be a better way since OO Perl is so ugly. Tried Python but didn't like that indentation was part of syntax and also didn't like the fact that you had to pass self into all of your instance methods. But Ruby was a good fit - it has the regex facilities of Perl but it's much cleaner especially when it comes to object oriented programming. Since Ruby was developed to be object oriented from the ground up it's much more consistent than Perl is and I find that I have to reach for the manual a lot less than I did with Perl. This consisency tends to make Ruby a joy to program in. If you haven't tried it, check it out: http://www.ruby-lang.org PhilArticle: 47884
Bas Arts <Bas.Arts_no_@_spam_philips.com> writes:
> > Can some one give me an introduction to low power SoC design . What is
> > difference from an ordinary design and low power design in the design stage
> > . Suppose I am designing a fsm based sequential logic , at which stage the
> > "LOW POWER " Comes in .
>
> Dependent on the type of design you are planning to design, you might also want
> to take a look at asynchronous design methods. If applicable, no synchronous
> method can give you less power consumption.
also, take a look at http://www.embedded.com/OEG20020913S0060
--
greetz, |\_____---_____
Bas |/ (__|||__)
"""
Article: 47885Hi, Can anyone give me an example of how to make a stamp files (.mod and .data) for a module. Best regards, MuthuArticle: 47886
Xpost without fllw-up2 Ray Andraka <ray@andraka.com> wrote: > beat the target. The real question is whether you are using the device anywhere > near its capability. As for comparisons, you need to be careful what you are > comparing it to. There is an astonishing amount of mediocre or worse design > going on out there. The fact that the average FPGA user only does one FPGA > every 18-24 months and the tools/devices are changed at a much faster rate than > that alone says that a large number of the FPGA designs are being done as > As I said, there is a place for such tools, but for the most part, it is > probably not appropriate for something where cost, power or density is an > issue. What tools like this do is lower the bar to make it more accessible for > those without the expertise. It is not a replacement for the expertise, just a > tool that lowers the bar somewhat. I used the toolset from Cynapps which is now DSForte for a system solving 3sat with dedicated HW and SW. Using the whole set allows you to describe HW in a syntax very near to VHDL, which I prefered for my part of the job. The advantage I saw came from better testbench developing using C++ and faster simulationspeed. Of course thats not what they want to sell their tools, because testbench development isn't exactly the theme our management want to buy *g*. I seldom found this aspect in the discussion traditional HDL vs C/C++ based. I agree with you, that the tools didn't replace expertise for problems you need expertise to solve. I didn't believe you will ever be able to squeeze out the design with high-level synthesis. But more and more you don't need to. No matter to take the next bigger and faster device [1]. So work could be done using high-level synthesis without wasting time for details no one cares about. > right. Synthesis allows you to get around that where needed. Does this tool > also allow it? Some of the other HLL tools do not, so they become very awkward > to make work when you are pushing into the corners of the envelope. Thats an interessting point. The version of the high-level synthesizer I used was a push-and-go. If the result fits it is the best solution you can get, if not you loose. I don't think thats a matter of high-level vs low-level synthesis but a matter of tool philosophy. I had to use Synplify these days (sadly not the full version) and miss all the switches Synopsys dc_shell would offer. On the other hand you don't need to have experience to use Synplify, where I needed weeks before I got first results from Synopsys [2]. bye Thomas [1] A bit ironically as most of my work consist of squeezing out smallest FPGA to the max, but in fact thats way I see all around me. [2] The first time I used Synopsys was hard :). Today I'm experienced to get some results but still lack the knowlegde to use the full potential of the tool. I wonder if ever someone will be able to use 100% of dc_shell if necessary.Article: 47887
@all: A big thanks to you for your very interesting ideas ! I will start evaluating your proposals this week. Keep up the good work, you have helped me a lot ! ArneArticle: 47888
Hi, Few days back I posted a message asking help for instantiation of memory blocks in Altera devices. I got a reply saying it can be used by using megawizard function. But I am facing a problem, because it asks for lpm library. which I dont have, can anyone please say me where can I get lpm library and its components?Article: 47889
This http://www.abelectron.com/java/broken_oscillator.html doesn't work, because inverting output and input signals have permanently the same voltage levels (2.5v = half power). Do CPLD's pins have enaught hysteresys for oscillation? Thanks for any advice.Article: 47890
I remember doing a FPGA based project with 10K100E parts from Altera in QFP208 packages on a two layer board. We had to solder the pins using a microscope but finally it was running like a charm! Using PROM did not add any complexity to the PCB but as the board needed two such FPGAs with LOOOOTS of connections between them, we had to place one of them on top, and the other one on the bottom side of the board. To be honest, we didn't route that little monster with hand, even Protel 99SE could not route more than %94 after 8 hours (more than 50 nets remained that even by hand you could not route all of them...). So we used SPECCTRA and it finished autorouting in less than 8 minutes with even stricter design rules! The moral of the story is to PROM or not to PROM, was not the question :) "Xu Qijun" <fly@high.com> wrote in message news:ank32f$vot$1@reader01.singnet.com.sg... > Yeah, to be honest I am a hobbyist. > I am not sure how I can make a good medium size FPGA on a twin layer PCB. > > > > "Holger Veit" <veit@borneo.gmd.de> wrote in message > news:slrnapqu7q.ae3.veit@borneo.gmd.de... > > Falk Brunner <Falk.Brunner@gmx.de> wrote: > > > "Karl" <Far@East.Design> schrieb im Newsbeitrag > > > news:3d9d3652@news.starhub.net.sg... > > >> Is there any FPGA which has an PROM on it so that we can program with > thie > > >> PROM instead of > > >> an external PROM which makes PCB difficult to do? CPLD is too small for > an > > >> application anyway. > > > > > > Actel has some. Lattice?? Other may have too. But whats the problem with > a > > > external PROM? They are available in tiny SO8 packages. And with serial > > > configuration, just 4 lines go between the FPGA and the PROM. Hardly a > PCB > > > design issue. > > > > I don't understand this issue either. You have a PCB issue anyway with > > FPGAs with some hundred I/O pins, or even a BGA package - almost no chance > > to do with a two layer PCB. An SO8 package for a serial PROM should fit > > anywhere, even a normal PLCC or SO flat pack Flash PROM. > > > > It is just probably a problem for hobbyists who have even difficulties > > with a two layer PCB. > > > > Holger > > > > -- > > Please update your tables to my new e-mail address: > > holger.veit$ais.fhg.de (replace the '$' with '@' -- spam-protection) > > > >Article: 47891
hmmmm your method seems very interesting. Can you provide some source codes? I find it difficult to follow the same path by just reading what you've written here. You know, such tricky methods are much more difficult to explain in plain English than C++ :) Regards Arahs "Narcís Nadal" <nnadal@terra.es> wrote in message news:4f3703fe.0210051234.78737c59@posting.google.com... > "Darryl Groom" <dgroom@continental-microwave.co.uk> wrote in message news:<ee795d5.-1@WebX.sUN8CHnE>... > > Has anyone tried to implement a tone detector based around a goertzel algorithm filter. I am looking for an example in VHDL or schematic form as we are experiencing difficulty in getting the System Generator software working to be able to pull our Matlab/Simulink model into the Spartan-II device we are currently using. > > Is the first time I heard about goertzel and had to do a search with > the google. Its very interesting but if you want a very fast and easy > way to detect DTMF tones or other frequencies perhaps I may help you. > > 5 years ago I began a project whith the slowest CPU I know, the ST6, > and was decoding DTMF from the telephone line to detect the numbers > typed from any phone of a house. Early becomes evident that the > methods learned in the university was unusables for that CPU and I > began investigating and simulating other ways. The solution came from > taking the essence of the Fourier Transform. I conver all analog > signal to digital without using the ST6'ADC, I feed an smith trigger > whith the analog line for doing right edges, and then directly to an > ST6 digital input. The Fourier resulting coefficients were stored in 8 > counters, each one representing a frequency. The counters with greater > values showed the frequencies received . > > I will try to explain it in my poor english, for detecting the tones > we dont need to calculate the exact values of the coeficients but only > the ones with greater values thus we can eliminate the final > calculations, making the resulting coeficients of the Fourier > Transform obtained multiplicating the right point of the sine and > cosine waves and adding or substracting the resulting value to others > obtained before. First at all I calculate this waves and put them in a > constant binary table which contains a "1" if the wave was >0 volts in > this point and a "0" if was <0 volts. The sum of values for making the > coeficients was stored in up-down counters, I thing 2 for every > frequency. > > You also need 2*n tables, been n the number of frequencies detected. > You dont need to multiplicate anything because the tables and the > input are 1 bit values, you only XOR the two values. Dont add the > resulting value to the others because is 1 bit wide, store it in a > counter. When the result was "1" I incremented the right counter, and > when was "0" I decremented it, or incremented another one. Well, I > dont remember exactly how it was but the simulations on BorladC++ > showed a strong correlation between the input frequences and the value > of the counters. I remember to simulate a lot and as more samples > taken more correlation done and the other counters had very low > values. > > It was incredible to put that in so slow CPU but it worked very well, > if you dont belive it you can simulate with a C++ program. If you > implement that in a FPGA I am sure the wasted recurses will be much > lower than whith the Goertzel Algorithm filter,and once the > simulations were done you can implement it in few hours, even in > schematics because it only has any counters, rom tables and xor gates. > Of course if you are interested I can give you more details and look > for the simulations. > > Narcís NadalArticle: 47892
Hi all, Can somebody answer this question ?? > I saw the whole discussion, but I would be extremely gratefule if some one >could some resource as to what are the rules to be followed , while >implementing low power designs in behavioral modeling. > > Is there a way to find the power consumption during the running. during hdl >simulation/ or is it necessary to perform spice simulations. Hope veterans like Ray Andraka, Ulises , Rudolf and others will come with an answer. thanks skillieArticle: 47893
Hi Skilwood, Thanks for considering me a veteran, but I am still a young chap trying to work in this tough business in these years :o) and have a lot of things to learn from Ray, Rudolf, Peter Alfke and all these guys... Anyway, PowerTheatre (SEQUENCE tool), it is used in ASIC design, and it stimates the power consumed in your design using your RTL code. You can get a dirty first stimation only loading your RTL code, and a 'scenario technology' (for example 1.8V 0.18u technology, normally these libraries are specific to your ASIC silicon vendor). You can also add a VCD (Value Change Dump format) file, this file is an output of most os the simulation tools (Modelsim...) and it gives PowerTheatre stimation of your signals' toggling rate. As you see is dependant of your testbench, it gives you very detailed information about power consumption, for each entity you get a figure. You can also do a gate-simulation. There are some tips you get from the tool to optimise power like RAM splitting, enabling/disabling areas, encoding... I wonder if these libraries are available for FPGAs, it would be great but I guess is rather difficult to stimate that in SRAM based designs. More info: http://www.sequencedesign.com/2_solutions/2b_power_theater.html I hope it helps. Ulises Hernandez Design Enginner ECS Technology Ltd. www.ecs-tech.com "skillwood" <skillwood@hotmail.com> wrote in message news:anrjtk$gu67t$1@ID-159866.news.dfncis.de... > Hi all, > > Can somebody answer this question ?? > > > > I saw the whole discussion, but I would be extremely gratefule if some > one > >could some resource as to what are the rules to be followed , while > >implementing low power designs in behavioral modeling. > > > > Is there a way to find the power consumption during the running. during > hdl > >simulation/ or is it necessary to perform spice simulations. > > Hope veterans like Ray Andraka, Ulises , Rudolf and others will come with > an answer. > > thanks > skillie > > > >Article: 47894
Muthu wrote: > > Hi, > > Can anyone give me an example of how to make a stamp files (.mod and > .data) for a module. > > Best regards, > Muthu For Xilinx technology, you can generate STAMP model only after MAP. After the design has been MAPped, trun TRCE with -stamp option. UtkuArticle: 47895
Hello, I am using VHDL design flow with XST. I want all the ports on my top level entity will be IOB and there should be Registers in the Vitrex2 IOB when ever possible. I have the XST Synthesis Options: - Add I/O Buffers: true - Pack I/O Registers into IOBs and the MAP Options: - Pack I/O Registers/Latches into IOBs: For Inputs and Outputs. But I don't get all Registers in the IOBs. I checked with the FPGA Editor that there are really Registers at the outputs but some of them didn't pack into the IOBs. So whats wrong? Why are there XST Synthesis and Map Options concerning the IOB Register use? please help peterArticle: 47896
There are some resptrictions for the use of INF, OUTFF and ENFF, eg. same clock and reset signal. Try to force the registers to IOBs in the ucf-file. Perhaps then ISE will tell you why its not possible. Tobias "itsme" <itsme@gmx.de> wrote in message news:anro5p$1r6$06$1@news.t-online.com... > Hello, > I am using VHDL design flow with XST. > I want all the ports on my top level entity will be IOB and > there should be Registers in the Vitrex2 IOB when ever possible. > I have the XST Synthesis Options: > - Add I/O Buffers: true > - Pack I/O Registers into IOBs > and the MAP Options: > - Pack I/O Registers/Latches into IOBs: For Inputs and Outputs. > But I don't get all Registers in the IOBs. > I checked with the FPGA Editor that there are > really Registers at the outputs but some of them > didn't pack into the IOBs. > So whats wrong? > Why are there XST Synthesis and Map Options concerning the > IOB Register use? > > please help > peter > > > >Article: 47897
Hi, I think my problem is caused by XST vhdl compiler. I found in the FPGA Editor that the Register which should be placed in the IOB has a feedback. So it can't be moved in the IOB. In my VHDL code I have some conditional assignments to the output signal and in some cases it should hold its old value. How can I tell the XST not to use the output of a register also as input? It should rather use the ClockEnable auf the Register. I thought the XST Option - Pack I/O Registers into IOBs will do that. "Tobias Stumber" <tobias.stumber@de.bosch.com> schrieb im Newsbeitrag news:anrpef$c6o$1@ns2.fe.internet.bosch.com... > There are some resptrictions for the use of INF, OUTFF and ENFF, eg. same > clock and reset signal. > Try to force the registers to IOBs in the ucf-file. Perhaps then > ISE will tell you why its not possible. > > Tobias > > "itsme" <itsme@gmx.de> wrote in message > news:anro5p$1r6$06$1@news.t-online.com... > > Hello, > > I am using VHDL design flow with XST. > > I want all the ports on my top level entity will be IOB and > > there should be Registers in the Vitrex2 IOB when ever possible. > > I have the XST Synthesis Options: > > - Add I/O Buffers: true > > - Pack I/O Registers into IOBs > > and the MAP Options: > > - Pack I/O Registers/Latches into IOBs: For Inputs and Outputs. > > But I don't get all Registers in the IOBs. > > I checked with the FPGA Editor that there are > > really Registers at the outputs but some of them > > didn't pack into the IOBs. > > So whats wrong? > > Why are there XST Synthesis and Map Options concerning the > > IOB Register use? > > > > please help > > peter > > > > > > > > > >Article: 47898
"xtalca" <xtalca@hotmail.com> writes: > hi all, > all ic manufacturers says that there IC is made of some .13 micron or .18 > micron technology. what exactly this dimension correspond to ? Usually (but not always) it refers to the physical length of the gate of the MOS transistors. Note that in these deep submicron days, the drawn and physical gate lengths are different. Kai -- Kai Harrekilde-Petersen <khp@vitesse.com> Opinions are mine...Article: 47899
Hello,
here is my little "test design"
All I want is that all Outputs P_DR_BANK are packed into registers of an IOB
in a Virtex2.
However all Outputs are Registers only P_DR_BANK(0) is mapped in a IOB
register.
P_DR_BANK(1) uses a Slice FF.
I found in the FPGA Editor that the Register which should be
placed in the IOB has a feedback. So it can't be
moved in the IOB.
In my VHDL code (see below) I have some conditional assignments
to the output signal and in some cases it should hold
its old value.
How can I tell the XST not to use the output of
a register also as input?
It should rather use the ClockEnable auf the Register which is
also available in IOBs.
I thought the XST Option - Pack I/O Registers into IOBs
will do that.
please help
peter
----------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity TEST_OUT_FF is
Port ( CLK: in std_logic;
REQUEST: in std_logic;
--- PAD Signals, should be in IOB Register
P_DR_BANK : out STD_LOGIC_VECTOR (1 DOWNTO 0)
);
end TEST_OUT_FF;
architecture Behavioral of TEST_OUT_FF is
-------------------------------------------------------
---------------------------------- State machine
type STATE_TYPE is (S_Idle, S_Active, S_Access);
signal State: STATE_TYPE;
BEGIN
---------Statemachine
FSM:process(CLK)
begin
if Clk'event and clk='1' then
P_DR_Bank(0)<='0'; -- Use this to get Register in IOB !! Why?
-- P_DR_Bank(1) with no IOB Reg!!
case State is
------------------
when S_Idle =>
if Request='1' then
State <= S_Active;
end if;
-------------------
when S_Active =>
P_DR_Bank <= "10";
State <= S_Access;
-------------------
when S_Access =>
P_DR_Bank <= "01";
State <= S_Idle;
when others =>
State <= S_Idle;
end case;
end if; -- CLK
end process;
end Behavioral;
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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