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
Hi, I am not a FPGA Designer so can't suggest best FPGA, but about the second question: > Does there exist some free VHDL software ? Hopefully with simulator. > Try Xilinx Webpack http://www.xilinx.com/products/software/webpowered.htm and/or VHDLSimli at http://www.symphonyeda.com -- Best FREE VHDL Simulator! HTH, Srini Soren 'Disky' Reinke wrote: > > Hi there. > > I am a total FPGA newbie, so i have a few questions. > > What would be the best fpga to start with ? > I just wanna play with simple things in the beginning like counters, small > controllers and stuff like that. > > It should be cheap and also easy to connect to a PC to program it. > > Please help me. > > -- > With many Thanks > > Soren ' Disky ' Reinke ICQ #1413069 > Remove IHSYD from email address when replying by email -- Srinivasan Venkataramanan (Srini) ASIC Design Engineer, Chennai (Madras), IndiaArticle: 30476
Rick Filipkiewicz wrote: > > Nicolas Matringe wrote: > > > "W.Turk" wrote: > > > > > > Hi Gang: > > > Now ,i use Modelsim5.5.When i load or run a large design,it > > > will always close automatic. > > > Why? > > > > I have the same problem and I think, as Utku suggested, that it is RAM > > related. > > It usually happens when I restart the simulation. It works fine after > > freeing some RAM. > > > > - > > Oh dear it looks like the memory leak, fixed in 5.4, has come back. If you > are running under NT use task manager to see what the vsim memory useage > is. What used to happen is that on every restart you could see 10-15MBytes > being added. I wonder if this RAM consume increase by restart would also happen under UNIX? Or this is restricted to Windows-based OSs? UtkuArticle: 30477
I've used Handel-C for a few years now, starting with a pre-release
version 2.0 and now adapting code to version 3, the DK1 version. Our
team here at CERN are going strong with it now. We build network
testing equipment, that means MACs, memory interfaces, network
protocols, traffic shaping and queueing, timing measurements, that sort
of thing. One of our boards has 35 Altera Flex10k50s. For my own part,
I have been involved at most levels of designs from schematics up to
VHDL and Handel-C (on FPGAs and CPLDs), to the software that runs the
show on a cluster of PCs.
I've had to do some very dirty things with Handel-C, because it didn't
(by itself) support all that we needed. Things like combining with
VHDL, and dual-port RAMs. But the latest edition "DK1", which is a
much-changed language, seems to have a lot of the needed features built
in now. (I've not used it enough to be sure, and some dirty things
are still required).
Its about time to clear up a few misconceptions about Handel-C.
Richard Erlacher writes:
> However, if they ever figure out how to make a language operate in
> parallel rather than serial fashion, it may evolve into something
> useful for this task.
Handel-C _is_ a parallel language.
Handel-C has explicit parallel statements, starting with "par". The
parallelism is very clear and easy to read. (IMO, what behavioural VHDL
should have been, with clean branch and join points in the control flow).
Judging from the responses here, a lot of hardware types see "C" and
assume that Handel-C is not a hardware language. You should get
familier with keywords like "par", "signal", "clock", "interface",
"chan" before assuming that Handel-C has much to do with C.
As Adrian E. Lawrence notes, it's thinly disguised Occam.
It's a lot nicer to read than Occam :-)
Actually it used to be that, but newer features are rather unlike Occam.
Version 3 of the language (the DK1 tool) introduces "signals", which
have different timing semantics to variables (not unlike VHDL's
variables and signals).
S. Ramirez <sramirez@cfl.rr.com> writes:
> I personally think that HDLs will evolve to C eventually, but the
> real problem is that HDL is only a part of FPGA design. Just ask
> anyone in this newsgroup about all of the problems involved with FPGA
> design. The majority of them are not HDL problems. Therefore, one
> cannot take a programmer (read: non hardware engineer), teach him/her
> Handel-C and expect him/her to simply start cranking out FPGA designs.
> That person will have to know about timing problems, metastability,
> floorplanning and a bunch of other skills that are commonly required
> to complete an FPGA design. Essentially, that person has to be a
> hardware person.
There are levels of hardware knowledge. If you've been supplied with a
board with FPGAs on, designed by people who knew what they were doing,
you don't need to know about termination resistors, lead inductance etc.
The digital logic simply works to a specified limit. Until it doesn't,
but then you call in the board designers and get them to fiddle with the
scope :-)
It is _very_ good to have at least one person who understands FPGA
design constraints, floorplanning perhaps (though I don't bother -- I
use Alteras and their current PAR kit ignores most fitting constraints
anyway ;), and what typical Handel-C code maps to on the FPGA. This
sort of knowledge seems especially important at the I/O interfaces to
other chips, and when explaining the importants of pipelines et al.
Were you to follow the Celoxica "reconfigurable computer" route, you'd
have received delivery of a package where I/O interfaces are also solved
for you, in a library. I've never used a packet like this: our reality
means that boards are custom-designed for specific problems, and every
board is different.
"niki" <guest@my.net> writes:
> I totally agree with you. HDL is for hardware modelling. It is 100%
> different from what software guys think in C prgramming. It is not that
> different from schematic drawing of hardware components. If you don't have
> a good idea about what hardware should be, you can't be a good HDL
> designer. (designer! not programmer...)
I've noticed the "firmware" folk, who know Handel-C and have a passing
familiarity with VHDL do understand how most of our more sophisticated
I/O interfaces work (written in highly-hacked Handel-C or
multi-clock-domain VHDL), but I'd guess they'd take an age to actually
write them.
I've also noticed that things like barrel shifters and pipelining are
still a big deal to them, so I do see there's still a gulf between
software-level design and thinking in terms of depth of logic. I've
also noticed that, although they fully understand Handel-C's kind of
parallelism, they are sometimes reluctant to use it. By contrast, a
VHDL designer prefers parallelism because its simpler than sequencing.
Having someone around who understands the FPGAs well seems to be pretty
helpful for the others. <ahem> But enough about me ;)
For the day to day "lets histogram the packet latencies today", or "we
need to match the diffserv field", or "can you add VLAN support?",
really no knowledge of the FPGA is required beyond knowing how much RAM
you have. This is where Handel-C excels at the moment, IMO.
Sometimes it really is a case of "we need feature X, how long?" and the
stunned looks you get when you implement the feature before they've
finished explaining the question are most satisfying :-)
cyber_spook <pjc@cyberspook.freeserve.co.uk> writes:
> Currently I work as a IT suport Eng. (Yuk!) but I'm watching Handle-C
> make a differance were I work - The hardware department look a little
> worried as one of the softy's is going grate guns with his evaluation
> copy of Handle-C.
I think you will see more and more of that. In my experience, having
worked with both VHDL and Handel-C, writing Handel-C is a rather
speedier process. I'd bet your softy has a fairly good idea what's
going on at the FPGA level, and if not it will come to them as they get
closer and closer to the timing constraints. Logic depth, pipelining
and sensible simple parallelism come to mind as Handel-C level concepts
that map well to FPGAs.
Rick Filipkiewicz <rick@algor.co.uk> writes:
> (*) This is not just to do with timing, metastability, etc. My fear
> here is that s/w types do not have the deep, ingrained, awareness that
> from day 1, hour 1, minute 1 of design start any mistake they make
> could be fatal. s/w bug = fix it & put a patch file on the Web, h/w
> bug = a $250K+ ASIC respin.
This _really_ doesn't matter with FPGAs. 10 minute design cycle, about
5 times slower than writing C on a fast day. Sure you _can_ scrutinise
the code carefully for hours, but sometimes it's easier to write the
obvious code, if it works great otherwise pull out the scope and ask
"what should I be seeing on the scope about here?".
It never costs $250k. Maybe $2000 when you realise you need a faster
FPGA :-)
> To support hardware modeling, it was necessary to extend C to allow
> the programmer to model the passage of time and the execution of
> statements in concurrent processes. Not that such a thing couldn't be
> done in C (Verilog is sometimes referred to as "C+-" ;-) , but the C
> extensions need to be done in a "standard" way, to encourage the
> support of third-party vendors (cell libraries, verification,
> synthesis...)
One of Handel-C's characteristics is that passage of time does not
appear explicitly in most programs. This is a big contrast with
Verilog, and it does (IMHO) make the Handel-C quite nice to read.
There's a "delay" statement but it's not often used.
Robert Carney <bobcarney@worldnet.att.net> writes:
> What I actually don't understand is why the C-based tools are needed ?
> Verilog is so easy to write that at the pure coding level any
> reasonably competent C/C++ programmer could pick it up in a couple of
> days. Then with a couple of years practice they might, if they have
> the right mentality (*), get to produce h/w that's not an embarrasment
> to their company.
Canned answers:
(a) It doesn't take a couple of years to produce good code with Handel-C
(IMO it doesn't with Verilog either).
(b) Handel-C is sometimes verbose than Verilog for similar functionality.
(c) Verilog expects you to understand the basics of clock signals and
so on. As it happens you can get by in Handel-C without
understanding how the logic is synthesised, nor with much
awareness of the clock signal. Don't expect to write a SERDES
this way of course :-) But it's useful for writing DSP-like
algorithms or network protocol processing on FPGAs, for example.
You can still optimise the timing, without the clock signal being
in your face.
(d) Counterpoint: You have a good point about Verilog being pretty
close to these C-like languages though.
Rick Filipkiewicz <rick@algor.co.uk> writes:
> I would agree & I would go further even than Simon. Although looking at
> Handel-C itself it seems that it would do the job it seems that the
> marketing strategy of these C-based HDL tools companies has very little
> to do with the technicalities. They are mostly trying to talk to
> managers and saying:
>
> ``Hey guys here are some tools that will allow you to throw away all
> those expensive, rare h/w types & replace them with off-the-shelf
> el-cheapo s/w grunts''
I agree. Before they were called Celoxica, Celoxica's site had
"application notes" with nothing of the technical depth we'd expect.
Thankfully they have renamed them "case studies" now. Also, don't
expect to learn the Handel-C language from documents on the web site!
(AFAIK you have to register to see the language reference manual). It
seems very much a marketing and community-building exercise. To be
fair, they do have an active on-line community via their site, should
you wish to register.
I have similar reservations about C Level Design. Anyone have a manual
for their Cycle-C product? I couldn't find anything except brochures,
fluff and screen shots on their web site. I daresay if I emailed them I
_might_ get a manual and maybe a trial version, but I don't have much
time for the attitude that isn't encouraging me discover the tool for
myself.
Robert Carney <bobcarney@worldnet.att.net> writes some more:
> the C extensions need to be done in a "standard" way, to encourage the
> support of third-party vendors (cell libraries, verification,
> synthesis...)
At the moment each company has its own language, its own GUI, and a big
lack of handy on-line tutorials. Like they'd rather not have everyone
using their languages. Perhaps they want hardware engineers kept well
away, you know how they'll just pick on the bad points without
appreciating the good points ;-) At one time, I saw on C Level Design's
web site that they weren't revealing how their Cycle-C language worked:
it was only going to be used by their internal design teams. This seems
to have changed with their reported new relationship with Altera.
There may be some hope for standards in this field, according to
articles about C Level Design:
http://www.dacafe.com/DACafe/NEWS/CorpNews2/20010319_2237.html
http://www.dacafe.com/DACafe/NEWS/CorpNews2/20010319_2213.html
When some kind of standard emerges, if anyone wants to support the
development of an open source tool, do let me know :-)
cheers,
-- Jamie
Article: 30478Kristian Rye Vennesland writes: > Hi Soren, > I would recommend an Altera FPGA, preferrably a MAX. They are easily > programmed trough a cable, which you can make yourself, > and the development software is free and easy > to use. I don't think the free version supports VHDL though. If you have a little bit of cash and good soldering skills, I don't recommand a MAX as they're rather small, and if you get any further than a few counters you'll run out of space. Go for a Flex instead. There's at least one "academic evaluation" board around with a Flex on it and LEDs etc, maybe you can get hold of one. Xilinx have something similar. cheers, -- JamieArticle: 30479
I am looking for a variety of SW/HW contractors for contracts in the DC Metro area. If interested please reply. -MarkArticle: 30480
you just use falling_edge instead ofrising_edge...
process (clk)
begin
if falling_edge(clk then
synchronous statements on falling edge go here....
end if;
end process;
"Damir Danijel Zagar" <damir.zagar@tipro.hr> schreef in bericht
news:9as8n5$5h3v$1@as121.tel.hr...
> How to synthesize project which uses falling edge clocking
> using Xilinx Foundation 3.x?
>
> Damir
>
>
Article: 30481
There is a lot of confusion made on what HDL and synthesis are.
When one writes a HDL model, he may be describing an algorithm, an
architecture or both. The abstraction level of the model can range
from technological gates to large abstract functional blocks.
If a model is designed for simulation purpose only, no limits should
apply on the complexity it can reach (except those related to the
performance of the computer on which the simulation is to be done).
In VHDL, for instance, it possible to design a simulable model of a
system, should it be modeled from logical gates or from complex
sequential processes (I suppose this is also true for Verilog).
If synthesis is considered, an important information must be taken
into account: what are the synthesis tool assumptions applying to the
input time model !...
These assumptions are implicitly contained in what is usually called
"level of modelisation". Indeed, most of the confusion comes from not
explicitly telling what "level of modelisation" is considered.
Actually, most of the synthesis tools rely on RTL modelisation, but
it is not the only modelisation level that can be considered. There
are some major levels applying to modelisation of digital systems:
- logical
- RTL
- behavioral
In a logical level description, all the VHDL processes should describe
only purely combinatorial "blocks" (of any complexity). Each process
describes the "algorithm" of a combinatorial "block". Complex systems
are designed interconnecting all this combinatorial blocks.
-- example of a VHDL combinatorial process
-- where a, b and s are std_logic signals
comb: process (a,b)
begin
if a=b then
s <= '1';
else
s <= '0';
end if;
end process comb;
In an RTL level description, the VHDL processes describe combinatorial
"blocks" (as in logic level descriptions) or synchronous "blocks". From
a practical point of view, each "synchronous" process describes a time-
limited algorithm, the algorithm of a clock cycle period. The algorithm
can be as complex as needed, the only limitation being the tool and the
computer limits.
-- example of a VHDL "synchronous" process with asynchronous setup
-- rst, clk, a, b and s are std_logic signals
synch: process (rst,clk)
begin
if rst='1' then
s <= '0';
elsif rising_edge(clk) then
if a='1' then
s <= b;
end if;
end if;
end process synch;
As all the operations described in the process are processed in the
same clock cycle, all the required hardware must be generated. If three
arithmetic operations are done in the same clock cycle, three operators
must be synthesized (of course, synthesis optimizations can eventually
generate less hardware).
A behavioral description may be compared to a parallel C program with
explicit synchronisations (with semaphores, mutex, signals, etc.). The
VHDL processes can be compared to C threads or processes. Each process
describe a sequential algorithm, not time-limited. For a synchronous
design, this means that the algorithm can spread on several clock
cycles.
-- example of a VHDL "behav" process
-- clk, a, b and s are std_logic signals
behav: process (clk)
begin
wait until clk='1';
s <= '0';
for i in 0 to 3 loop
wait until clk='1';
s <= (not s) and (a or (not b));
end loop;
while true loop
wait until clk='1';
end loop;
end process synch;
Much more complex behaviors can be described, and if the model is not
synchronous, it may be very hard to find what hardware can match the
algorithm. Most of the time, there can be several different solutions.
Indeed, it is possible to write an asynchronous model that will be
implemented in a synchronous way. The synthetiser will have to determine
simultaneously, the number of cycles and the hardware ressources. That
is, find an architecture and match the algorithm on this architecture
!...
And this is a quite complicated task. This is a reason for which this
kind
of synthetiser is not yet the industry standard.
When behavioral synthetisers will be a standard, it will be possible to
use C-like languages or VHDL or Verilog (or else) indiferently.
However, if one still needs to control the generated architecture in its
model, he will still need to use RTL or logical modelisation. And this
is
not possible (yet?) with traditional algorithmic languages as C or C++.
--
+-----------------------------------------------+
Fabrice MONTEIRO
LICM / CESIUM
Universite de METZ
7, rue Marconi
57070 METZ / FRANCE
Phone: +33 (0)3.87.54.73.11
FAX: +33 (0)3.87.54.73.01
Email: fabrice.monteiro@ieee.org
+------------------------------------------------+
Article: 30482Dear NG! I have started recently with CPLDs and ABEL-HDL and need some advice on how to continue. For my first steps I have been using the starter kit offered by Lattice/Vantis and did the tutorials on the CD. I was then able to do a 4-digit BCD up/down counter with clear, which is the obvious thing to try first, since the kit includes a board with four 7segment displays and 3 keys for user entry. Great so far. But now I'm stuck with syntax questions and timing problems that I can't solve with the manuals. So now I need some more advanded literature or example designs for evaluation. Can anybody help with that? -- many thanx Richard KnispelArticle: 30483
the basic "par" statments looks somthing like this... Please correct me
if im wrong... I'll post some real code If I can get my hands on it.
par
{
this responds to the first clk and runs in paralle with the next bit
below.
}
par
{
in parralle with bit above on first clk..
par
{
nested parralle functions that respond to the second clk..
}
par
{
......
}
}
Article: 30484I used altera. I first used the MAX7128 (2500 gates) in the PLCC format - that way you can plug it into a PLCC though hole socket on a bit of vero board. Next was a FLEX10K (10,000 gate version) that you can also get in a 84pin PLCC package. I used a EPC2 which a device that 'configures' the FLEX10K each time you power up with your code (the FLEX10K is SDRAM based not EEROM like the MAX7000's) and the EPC2 can be programed just like the MAX7000's though the byte blaster (cct diagram can be found on altera to make your own - which I did!). Software - Downloaded the MAX+Plus v10 and FPGA Express from Altera (Both FREE). Use the FPGA Express to complie the VHDL and generate a EDIF file that MAX+Plus can then make into a floor plan to program the chips with and you can then simulate it. Both are limited but will do a fine job on the smaller chips. A better simulater is ModleSim which you can get on a 30day tril but will set you back £5k ish - however I belive that if you get Qualtus (Altera) wich will complie you code - you get a 'Altera only' vertion of Modle Sim though in too! (£1.5k ish). cyber_spook Soren 'Disky' Reinke wrote: > Hi there. > > I am a total FPGA newbie, so i have a few questions. > > What would be the best fpga to start with ? > I just wanna play with simple things in the beginning like counters, small > controllers and stuff like that. > > It should be cheap and also easy to connect to a PC to program it. > > Does there exist some free VHDL software ? Hopefully with simulator. > > Please help me. > > -- > With many Thanks > > Soren ' Disky ' Reinke ICQ #1413069 > Remove IHSYD from email address when replying by emailArticle: 30485
>> Any suggestions for an FPGA or CPLD that can do the following? >> >> slow I/O: 10 Mhz TTL/LVTTL inputs (4), clock (1), and outputs(18). >> fast I/O: 200 Mhz PECL clock (1) producing 100 Mhz output (1). [I want >> plenty of margin on this, not just squeeking by at 200 Mhz.] >> >> Basically, a small PLD that can do fast PECL as well as traditional >> slower TTL. >> >> Any ideas? > >Do you also need PECL output? >I am experimenting with PECL input to Spartan-II FPGA by configuring the >input as GTL and using a higher VREF. >I have no results yet, but it should work. > >There are also affordable CMOS level clock synthesizers available at 200 >MHz. Here's something you might try if you to want your non-LVPECL 3.3V PLD to drive LVPECL without having to go through level converter chips. IIRC, LVPECL inputs can swing from ground to a diode drop below the 3.3V rail. Start with a non-LVPECL 3.3V PLD, such as something in the Lattice 5K-series, Altera 7K-series, Xilinx CoolRunner, etc. - whatever is fast enough and properly sized to your needs. Make the non-LVPECL output of your PLD open-drain and connect it to your LVPECL load along with the following odd pullup: Take a silicon diode and attach its anode to the 3.3V rail. From its cathode add a resistor (330 Ohms or so as a guess) paralleled by a 0.1uF bypass cap to ground. Call the cathode side of the diode V_HIGH. The resistor to ground makes sure the diode is always on, and the cap minimizes noise on V_HIGH by making V_HIGH appear to be a low-impedance source at your clocking frequency. Add a resistor of the characteristic impedance of the LVPECL signal line you're dealing with (to minimize ringing and reflections) from V_HIGH to your LVPECL load. With this setup your non-LVPECL PLD, along with the odd pullup, will drive the LVPECL load within "legal" bounds, although those bounds will be outside the normal LVPECL operating range on the low side. The devil is in the details, of course, and it would be interesting to see if this odd passive pullup is sufficient to work at the speed you have in mind. A further refinement might be to cut the voltage swing seen at the LVPECL load by adding a series resistor between the PLD open-drain output and the LVPECL load, and putting the odd pullup at the LVPECL load side of the series resistor. This way the diode sets the high LVPECL voltage, and the resistor divider made up of the resistor from V_HIGH to the LVPECL load and the series resistor sets the low LVPECL voltage. Some experimentation is called for. You might want to grab Motorola Application Notes AN1404, AN1406 and AN1672 off the On Semiconductor (formerly a division of Mot., www.onsemi.com ) website for interesting thoughts on PECL. As for getting an LVPECL clock into your non-LVPECL PLD..., well, no clever ideas come to mind. It may be that the output swing of an LVPECL gate with a resistor to ground is sufficient to clock a non-LVPECL PLD, but that is "an exercise left for the reader." <grin> On Semiconductor recommends you use their MC100EPT21 chip, or some other member of that family. Good luck and please e-mail or post your results, whatever you end up doing.Article: 30486
Thanks, Ray. --Yury Wolf Ray Andraka wrote: > The power on reset happens whether you specify a global reset or not, and > regardless of whether or not your logic has async resets on it or not. For > synthesis, you needn't do a thing if you don't have a reset pin on your design. > If you want to simulate it however, then use the ROC component in the unisim > library. It gets connected to your Global reset net. You can leave it in there > if you want. Synthesis will put the ROC in your design as a black box, and the > xilinx software will ignore it. > > yuryws@banet.net wrote: > > > > Would like to implement Power-On-Reset. Use no external Reset pin. > > Asynchronous RST is used throughout the design on all flops/memories. > > > > What is the procedure for tying GSR to RST during synthesis (FPGA > > Express user)? > > > > Thnx. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.comArticle: 30487
Hi Jim! Could you please elaborate on your application? I am interested in learning how the Atmel part draws less power than the CoolRunner at low frequencies. I have heard that the CoolRunner devices may have some competition at ultra high frequencies, but not at the bottom end. (Maybe if there are no signals to process?) In one of Atmel's data sheets for their device ( http://www.atmel.com/atmel/acrobat/doc1409.pdf ) on page 16 they show a power consumption vs. frequency that 'starts out' at about 35mA or so. The test cases are typically synchronous counters... I poked around looking for a description of the test but did not find one. CoolRunner devices "start out" at well below 100uA and linearly ramp. You have to clock the 64mc CR parts at about 90MHz before they draw the same amount of power that the Atmel part draws _at_quiescent_. It appears that the ATF1504ASVL parts have a very complex power management system... PD pins, "L" mode, automatic shutdown, etc. While these do look appealing initially, it seems that you have to put up with a fairly hefty latency period before the part can actually process the data. With the PD mode, it appears that the entire device ignores any transitions on the inputs until released from PD, which takes 1us to get out of. Surprisingly, the device can still draw as much as 5mA while in this mode. I can't imagine the headache of doing a timesim for this device. But... people needing ultra low power designs (at ultra-low bandwidths) might be willing to put up with all the hoops. If absolute low power is the ultimate concern, the best solution might be a PIC processor. But that opens up a whole bunch of other issues. Best Regards, Frank 'I ain't biased' Wirtz Xilinx Staff Applications Engineer 7801 Jefferson St. NE Albuquerque, NM 87109 (505) 798-4812 > Jim Granville <jim.granville@designtools.co.nz> wrote in message > news:3ACE8160.F3@designtools.co.nz... > > > It depends a lot on your frequency, and on the technology. > > All devices have a DC current, and a mA/MHz slope. > > As the clock frequency increases, all logic will draw more current. > > > > We are studying CPLD for LCD drivers, and sub 10uA (typ) is looking > > feasible, > > in ATF1504ASVL series - at low freqs these draw less than coolrunner, > > > > So, if you are using these as IO, and not at tens of MHz, look at the > > ATF15xx family. > > > > Also, given CMOS process nature, VERY low Idd will be easier at 3V than > > 5V. > > > > - jg > > -- > > ======= 80x51 Tools & PLD IP Specialists ========= > > = http://www.DesignTools.co.nzArticle: 30488
Frank, Not to wade in, but I can't help it. A long time ago, I was fooled into buying the "new lower power" part from aa competitor. It had all of the problems you mentioned: intitial DC current was greater (not true CMOS), it had a start up transient that required even more current (it had charge pumps), and it had a "sleep" mode to save power. Suffice it to say, after wasting about a month, we gave up, and went back to the original part that did not have any of this personality, Austin Frank Wirtz wrote: > Hi Jim! > > Could you please elaborate on your application? I am interested in learning > how the Atmel part draws less power than the CoolRunner at low frequencies. I > have heard that the CoolRunner devices may have some competition at ultra high > frequencies, but not at the bottom end. (Maybe if there are no signals to > process?) > > In one of Atmel's data sheets for their device ( > http://www.atmel.com/atmel/acrobat/doc1409.pdf ) on page 16 they show a power > consumption vs. frequency that 'starts out' at about 35mA or so. The test > cases are typically synchronous counters... I poked around looking for a > description of the test but did not find one. CoolRunner devices "start out" > at well below 100uA and linearly ramp. You have to clock the 64mc CR parts at > about 90MHz before they draw the same amount of power that the Atmel part draws > _at_quiescent_. > > It appears that the ATF1504ASVL parts have a very complex power management > system... PD pins, "L" mode, automatic shutdown, etc. While these do look > appealing initially, it seems that you have to put up with a fairly hefty > latency period before the part can actually process the data. With the PD > mode, it appears that the entire device ignores any transitions on the inputs > until released from PD, which takes 1us to get out of. Surprisingly, the > device can still draw as much as 5mA while in this mode. I can't imagine the > headache of doing a timesim for this device. > > But... people needing ultra low power designs (at ultra-low bandwidths) might > be willing to put up with all the hoops. If absolute low power is the ultimate > concern, the best solution might be a PIC processor. But that opens up a whole > bunch of other issues. > > Best Regards, > > Frank 'I ain't biased' Wirtz > Xilinx Staff Applications Engineer > 7801 Jefferson St. NE > Albuquerque, NM 87109 > (505) 798-4812 > > > Jim Granville <jim.granville@designtools.co.nz> wrote in message > > news:3ACE8160.F3@designtools.co.nz... > > > > > It depends a lot on your frequency, and on the technology. > > > All devices have a DC current, and a mA/MHz slope. > > > As the clock frequency increases, all logic will draw more current. > > > > > > We are studying CPLD for LCD drivers, and sub 10uA (typ) is looking > > > feasible, > > > in ATF1504ASVL series - at low freqs these draw less than coolrunner, > > > > > > So, if you are using these as IO, and not at tens of MHz, look at the > > > ATF15xx family. > > > > > > Also, given CMOS process nature, VERY low Idd will be easier at 3V than > > > 5V. > > > > > > - jg > > > -- > > > ======= 80x51 Tools & PLD IP Specialists ========= > > > = http://www.DesignTools.co.nzArticle: 30489
Damir Danijel Zagar wrote:
>
> How to synthesize project which uses falling edge clocking
> using Xilinx Foundation 3.x?
Simply write your code so that it looks at the falling edge of the
clock:
process (clk) is
begin
if falling_edge(clk) then
...
or
always @(negedge clk) ...
Note that FPGA Express v3.4 is brain dead, and instead of taking
advantage of the FPGA's clock-polarity select mux, it will infer an
inverter on the clock, run the output of the inverter through a BUFG,
and THAT'S what clocks your flop. I don't know if it was fixed in v3.5,
nor do I care.
--andy
Article: 30490
> cheers,
> -- Jamie
Jamie,
You've covered a lot of ground, so I won't bother to elaborate on what
you said; however, I really do appreciate your insight into Handel-C, since
you have knowledge of this language AND VHDL and Verilog.
Thanks for your explanations.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 30491Frank Wirtz wrote: > > Hi Jim! > > Could you please elaborate on your application? I am interested in learning > how the Atmel part draws less power than the CoolRunner at low frequencies. I > have heard that the CoolRunner devices may have some competition at ultra high > frequencies, but not at the bottom end. (Maybe if there are no signals to > process?) So you learn something new every day :-) The 5V coolrunners we checked ( I believe now dropped ? ) have a just under 100uA static current (typ), whilst the ATF1504 is around 8uA at 5V, and appx 3uA at 3V (typ) I couldn't find TYP numbers for the 3V Coolrunners ? From there, the mA/MHz slope is higher on ATF than coolrunner, but this was for a LCD app, so you don't move far up the MHz scale! 64-128Hz backplane freq are LCD regions, which is close to your 'no signals to process'. Our design target is to have the LCD display 'alive' and everything else asleep, as that determines long term battery life. <snip> > It appears that the ATF1504ASVL parts have a very complex power management > system... PD pins, "L" mode, automatic shutdown, etc. While these do look > appealing initially, it seems that you have to put up with a fairly hefty > latency period before the part can actually process the data. With the PD > mode, it appears that the entire device ignores any transitions on the inputs > until released from PD, which takes 1us to get out of. Surprisingly, the > device can still draw as much as 5mA while in this mode. I can't imagine the > headache of doing a timesim for this device. I've never used this 'legacy' mode, it's far easier to use the smarter Automatic 'L' mode, which has a simple <10nS time adder. > But... people needing ultra low power designs (at ultra-low bandwidths) might > be willing to put up with all the hoops. No hoops, just cut the code... But to chase uA operations with any CMOS device, you do need to ensure Vcc signal swings, or the input buffers draw significant ( in uA terms ) current. > If absolute low power is the ultimate concern, the best solution > might be a PIC processor. But that opens up a whole bunch of other issues. Nope, PICs struggle to meet our power and price targets. -jgArticle: 30492
Ouch, that hurts. I want to be considered a 100% reliable, honest source of information, and I goofed. Sorry for that! But there is a silver lining: When we first found out that the dynamic phase adjust sometimes locks up, we immediately added this "function not available" into the errata sheet. Better safe than sorry, for Murphy never sleeps. In the meantime, we have analyzed the behavior, scratched our heads individually, found the root cause and fixed it ( together with the other limitations mentioned in the errata sheet) for the production ( non-ES ) silicon, to be available in a few months. If you want to try out the dynamic phase shift feature, it works almost all the time, but it can lock up under very specific circumstances. Good enough for lab work, but I do not recommend it for a production design. As I said, the problem is well-understood and fixed for non-ES silicon. Peter Alfke, eating humble pie =================================================== Erik Widding wrote: > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > news:3ACDFFEC.BEFA4706@xilinx.com... > > Yes, yes: The phase can be programmed by configuration, but the phase can > also > > be adjusted during normal operation by pulsing the increment/decrement > input of > > the DCM. See the description on pages 171...175 of the Virtex-II Handbook. > > I think to be accurate, this should be a qualified "yes". The engineering > samples of the XC2V40 and XC2V1000 do not support this feature. According > to the errata we received with some XC2V1000-4FG256CES parts, last week: > "DCM Fine Phase shift operation - the "variable" shift mode of the DCM > Fine Phase Shift feature is not available in these devices. "Fixed" shift > mode is available for use." > > If you need the feature, you will probably have to wait for the next die > revision. Admittedly, I have not yet checked for a possible workaround, as > we weren't planning on playing with this feature for at least a couple of > weeks. > > Regards, > Erik Widding. > > -- > Birger Engineering, Inc. -------------------------------- 781.481.9233 > 38 Montvale Ave #260; Stoneham, MA 02180 ------- http://www.birger.comArticle: 30493
I am afraid that you mixed design domains and levels of abstraction into the same concept. Levels of abstraction contains (1) architectural (2) algorithmic (3) functional blocks (4) logical (5) circuit levels from highest to lowest. Design domains are comprised of (1) behavioural (2) structural (3) physical modelling. Usually, when they talk about synthesis, this means logical abstraction level. It is called RTL in terms of structural modelling. Behavioural modelling doesn't necessarily mean that there is no logical abstraction. This is well explained in the chapter 1 of "Principles of CMOS VLSI design" by Weste and Eshraghian. -NikiArticle: 30494
You may have a better result using Coregen. -NikiArticle: 30495
I have an additional questions to this:
If I have no explicit reset signal in my design, how do I specify the reset value of a
DFF?
Thanks,
Kolja
> > The power on reset happens whether you specify a global reset or not, and
> > regardless of whether or not your logic has async resets on it or not. For
> > synthesis, you needn't do a thing if you don't have a reset pin on your design.
> > If you want to simulate it however, then use the ROC component in the unisim
> > library. It gets connected to your Global reset net. You can leave it in there
> > if you want. Synthesis will put the ROC in your design as a black box, and the
> > xilinx software will ignore it.
> >
> > yuryws@banet.net wrote:
> > >
> > > Would like to implement Power-On-Reset. Use no external Reset pin.
> > > Asynchronous RST is used throughout the design on all flops/memories.
> > >
> > > What is the procedure for tying GSR to RST during synthesis (FPGA
> > > Express user)?
> > >
> > > Thnx.
> >
> > --
> > -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
Article: 30496Richard Knispel schrieb: > > For my first steps I have been using the starter kit offered by > Lattice/Vantis and did the tutorials on the CD. I was then able to do a > 4-digit BCD up/down counter with clear, which is the obvious thing to > try first, since the kit includes a board with four 7segment displays > and 3 keys for user entry. Great so far. > > But now I'm stuck with syntax questions and timing problems that I can't > solve with the manuals. Do you have the comlete ABEL reference and design manuals and als looked at them ? When yes, what syntax question ist still unsolved ? (i cannot say anything about timing issues) greetings, Bertram -- Bertram Geiger, bgeiger@aon.at HTL Bulme Graz-Goesting - AUSTRIAArticle: 30497
Hi all, Mmm, I didn't get any reply for my previous posting. But anyway, after I upgraded to Servie Pack 7, the DLLs are locking OK. Thanks. TA TA kahhean ----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web ----- http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups NewsOne.Net prohibits users from posting spam. If this or other posts made through NewsOne.Net violate posting guidelines, email abuse@newsone.netArticle: 30498
Well, I was trying to discuss about the different levels of abstraction,
not on design domains.
If all processes on which rely a hierarchical VHDL model are RTL
compliant,
the model is RTL compliant. Thus, in order to design RTL models, one
must
write RTL processes.
Different architectures can match an given algorithm. In RTL, each
process
describes the architecture of a "sub-block" of the design. Note that i
am
not talking of structural VHDL.
I give in the following, examples of different architectures for the
same
algorithm. All are synchronous clocked designs. Let the algorithm be the
following:
algorithm:
-> wait until a wait_signal is reset
-> compute the sum of stored integer numbers
-> set an end_signal
-- VHDL design nr 1
addOne: process (rst,clk)
variable i: integer;
begin
if rst='1' then -- asynchronous initialisation
total <= 0;
i:=0;
end_signal <= '0';
elsif rising_edge(clk) then
if wait_signal='1' then -- synchronous initialisation
total <= 0;
i:=0;
end_signal <= '0';
else
if i<size_of_my_array then
total <= total+my_array(i);
i:=i+1;
else
end_signal <= '1';
end if;
end if;
end if;
end process addOne;
-- VHDL design nr 2:
addTwo: process (rst,clk)
variable i,j: integer;
begin
if rst='1' then -- asynchronous initialisation
total <= 0;
i:=0;
j:=1;
end_signal <= '0';
elsif rising_edge(clk) then
if wait_signal='1' then -- synchronous initialisation
total <= 0;
i:=0;
j:=1;
end_signal <= '0';
else
if i<size_of_my_array then -- supposing size_of_my_array is even
total <= total+my_array(i)+my_array(j);
i:=i+2;
j:=j+2;
else
end_signal <= '1';
end if;
end if;
end if;
end process addTwo;
-- VHDL design nr 3:
addAndShift: process (rst,clk)
variable i: integer;
begin
if rst='1' then -- asynchronous initialisation
total <= 0;
i:=size_of_my_array;
end_signal <= '0';
elsif rising_edge(clk) then
if wait_signal='1' then -- synchronous initialisation
total <= 0;
i:=size_of_my_array;
end_signal <= '0';
else
if i/=0 then
total <= total+my_array(0)
my_array <= my_array(0) & my_array(size_of_my_array-1 downto
1);
i:=i-1;
else
end_signal <= '1';
end if;
end if;
end if;
end process addAndShift;
All the designs implement the same algorithm but not the same
architecture.
On the first design, once the start_signal is set, size_of_my_array
clock
cycles are required to compute the sum. The stored data my_array is in a
single ROM or RAM (only one address must be reached at a time). Only one
adder is required to add the data to the total. The data addresses are
generated by a counter.
Only (size_of_my_array/2) clock cycles are required on the second
design.
But the data must be partitionned into two different ROMs or RAMs (as
two
addresses must be reached at a time), one for the odd addresses, the
other
for the even addresses. Two adders are required to add the data to the
total. The data addresses are generated by two counters.
In the third design, the data is stored in a cyclic shift register. The
number
of clock cycles required to compute the sum is (size_of_my_array). The
counter
i is only used to know if all data was processed, as no ROM or RAM
address
must be generated.
--
+-----------------------------------------------+
Fabrice MONTEIRO
LICM / CESIUM
Universite de METZ
7, rue Marconi
57070 METZ / FRANCE
Phone: +33 (0)3.87.54.73.11
FAX: +33 (0)3.87.54.73.01
Email: fabrice.monteiro@ieee.org
+------------------------------------------------+
Article: 30499Hi all, Recently, I had problems with DLL locking. After upgrading to Service Pack 7, and FPGA Express (3.5.0.6013), the DLLs are locking fine. However, the very same vhdl code that used to be synthesized to be under 8 ns, is now 18ns component delay alone. After checking in Timing Analysis, I observed that FE seems to be giving me rubbish. I have a 38-state state machine. I specified one-hot encoding. The result is that I get 38 flip flops for the state machine (which looks like one-hot), but I also get each state talking to every other state. Since each of my state transits to only a few other states, FE must be giving me rubbish. Anyway, the very same vhdl code synthesized well using FGPA Express 3.4. Does anybody have the same experience too? Thanks in advance. TA TA kahhean ----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web ----- http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups NewsOne.Net prohibits users from posting spam. If this or other posts made through NewsOne.Net violate posting guidelines, email abuse@newsone.net
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