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 implementing a state machine in a FPGA using VHDL.
Several states are determined by 4 external event inputs (falling
edge) which occur asynchronously to the 25MHz FPGA clock (I might need
to increase to 50MHz). The events occur at random intervals of 10us or
more.
I have a couple questions which someone may be able to guide me on:
1) Should I have a synchroniser (2-stage shift reg) at each of the 4
event inputs before being sampled by the state machine to avoid
meta-stability problems?
2) I'm using the following VHDL code to detect a falling edge on the
event inputs. Is there a better way?
process( clk, ev1, ev2, ev3, ev4, reset)
variable prev_ev1: std_logic;
variable got_ev1: boolean;
<variables for other events omitted>
begin
if (reset = '1') then -- reset the event states
prev_ev1 := event;
got_ev1 := false;
elsif (rising_edge(clk)) then
if (event = '0') then -- event signal is low
if (prev_ev1 = '1') then
got_ev1 := true; -- falling edge detected
end if;
prev_ev1 = '0'
else
prev_ev1 = '1';
end if;
<repeat edge detection for the other events>
<process 'got_ev' flags in state machine & reset them>
end if;
end process;
Any advice welcome!
Thanks
Dave
Article: 78401"Rick North" <nobbe@acc.umu.se> schrieb im Newsbeitrag news:4bbdba0c.0501310902.4dc320b1@posting.google.com... > Hi All, > > I have several BRAMs in my design each needs its own set of constants. > So far I have used the ucf file to store my BRAM values. But it has > become error prone and tedious. I would like to have a command for the > ucf such that I can "link" a generated file in to the ucf and its > format. > > Something like: > MyBRAM => file:MyBramFile.dat > where MyBramFile contains > " > 0000002800000028000000280000002800000028000000280000002800000028 > 0000002800000028000000280000002800000028000000280000002800000028 > "...etc > > is this possible in some way? Use data2mem utility. It can directly write BRAM content into a BITFILE, so after the complete implementation process. Very nice feature when you develop a FPGA based uC application (Picoblaze, Microblaze whatever) This tool nees a special data file, (*.mem) but its very easy structured Just a start address like @0000 AA, BB, CC, DD etc. Very easy to generate via a script/tool. Regards FalkArticle: 78402
Johnson Liuis wrote: > I heard that Lattice Semiconductor Corporation boasted they were providing > the lowest-cost FPGA and CPLD solutions, not sure if the news was true. > Could anybody confirm it? If so could anybody give me a price range for > their lowest-cost solution? > > I always have an impression that Xilinx provided the lowest-cost chip while > Altera provided the high-performance one, is it still true? How is the > Lattice compared to Xilinx and Altera? > > Thanks. > > Johnson > > http://www.latticesemi.com/products/index.cfm Claims like "lowest cost" or "highest performance" are pretty meaningless in the context of designing with an FPGA. No matter what they measure or how they measure it, unless they are using your exact design, it is not valid for your needs. Also, the advertised price is almost never a price you will actually see. Its a bit like automobile prices. They advertise a super low price on the model sitting in the back of the lot in the avocado green color with the diesel engine and the vacuum powered wipers. But if you want a car you can drive home, its going to cost a "little more". I think they all have pretty good products and when it comes to pricing, you are on your own to get whatever price you can from your distributor; although I did once get better pricing by showing a sales rep an ad that claimed some price superiority on a new family line. When I later tried to do a little better on the same part in a smaller package I was told that they could not improve on the previous quote because I was already getting the 50k price on quantity of a few k per year. Interestingly enough, this 50k price was still more than a factor of 3 higher than the advertised price for 250k per year. I guess its not until you start using a full production line capacity that you get the *real* price breaks... ;^) -- Rick Collins rick.collins@XYarius.com Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave. 301-682-7772 Voice Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.comArticle: 78403
Don't forget, it's tomorrow, Tuesday, at noon Pacific Time. Altera Marketing has e-mailed me and promised their attendance. I will not disappoint them. So join me tomorrow for some serious and fun talk on FPGA performance. Peter > "Peter Alfke" <peter@xilinx.com> wrote in message > news:1106877046.479990.51180@z14g2000cwz.googlegroups.com... > > > > > > If you click on > > > > http://seminar2.techonline.com/s/xilinx_feb0105 > > > > and register for the Feb.1 Xilinx TechOnLine, then you can witness my > > presentation about Virtex-4 performance. It's a daring high-wire act > > between engineering and marketing. Wish me luck! > > > > The time is Tuesday, Feb 1, noon to 1 pm Pacific time. > > It would be nice to feel that I can count on some friends in the > > invisible audience. > > > > Peter Alfke, Xilinx Applications > > > >Article: 78404
Hi Gabor, I think the point is, that with tiny loads on the output, i.e. small traces, the outputs swing very quickly to whatever voltage the current sources can provide. This probably remains within the range of the FPGA's diff inputs, they're very good and wide. I don't see how having 'guaranteed AC content' makes any difference. Could you explain what you mean by that? Do you mean enough edges, or no DC? As you say, I'd certainly have to try it first, the datasheet is not clear on the output structure. See appnote HFAN-01.0 from Maxim for an overview of their output structure. Dunno what the Texas one looks like. On the other hand, I'd be very nervous about doing this. Especially with an enormous 80 pin PQFP package driving the outputs. Again, think of the hideous leadframe. Like you say, you'd have to prototype it first. Kolja, You do know that you can get 8x100 resistors in two packs sized 2x1mm? Rohm, AVX, Koa etc.. have gone to a lot of trouble to make these bits. Use them! http://www.avx.com/docs/Catalogs/crb-crc.pdf And fix your PCB technology, your competitors will! Cheers, Syms. "Gabor" <gabor@alacron.com> wrote in message news:1107179024.417762.98680@f14g2000cwb.googlegroups.com... > > > at these very short signal lengths. What I am concerned about is the > > current mode driver characteristic as described by Gabor. > What bothers me about leaving out terminators, especially in your case > where you're not running 8b/10b or some other code with guaranteed > AC content, is what happens when the output has been in one state long > enough to generate a wide voltage spread.Article: 78405
Jedi wrote: > Luc wrote: > >> No, no, >> >> It is called XP, based on 130nm flash tech from fujitsu. >> Performance-wise like the EC,and non-volatile like the ispXPGA. But >> this was EČ, and therefore a lot more expensive. You can expect the XP >> in the price range of the EC. > > > Actually price range will be EC + external SPI flash (o; > > > rick > > >> >> Regards, >> >> Luc >> >> On Thu, 27 Jan 2005 11:09:52 -0800, "Antti Lukats" >> <antti@openchip.org> wrote: >> >> >>> ispXPGA? those are "old" stuff it was available long time before >>> EC/ECP was announced, I did think jg was referring something new, eg >>> not-announced lattice product... >>> >>> antti >> >> >> I think that the XP replaces the "DSP blocks" in the ECP device with flash (EEPROM) memory blocks for storing the configuration bits. BenArticle: 78406
On 31 Jan 2005 09:33:49 -0800, daveb_24_7@yahoo.co.uk
(Dave) wrote:
>I am implementing a state machine in a FPGA using VHDL.
>Several states are determined by 4 external event inputs (falling
>edge) which occur asynchronously to the 25MHz FPGA clock (I might need
>to increase to 50MHz). The events occur at random intervals of 10us or
>more.
>
>I have a couple questions which someone may be able to guide me on:
>
>1) Should I have a synchroniser (2-stage shift reg) at each of the 4
>event inputs before being sampled by the state machine
Yes, absolutely, unless you have an astonishingly cunning state
machine design...
> to avoid meta-stability problems?
AARGH, no, that's not the reason.
Saddle-up the old warhorse, and back in to battle once again...
Most people who *think* they have a problem with metastability,
don't. Instead they probably have a problem with input hazards.
OK, so what's an input hazard? It's any situation where an
asynchronous input can affect more than one flip-flop.
If this asynch input should change painfully close to a clock
edge, you will of course get setup/hold violations on the flops.
This in itself rarely causes a problem, because each flop
individually will either respond to the changed input or it
won't. The problem happens when one of the flops DOES respond,
and the other DOESN'T. When this happens you get an internal
state change that was not expected. It will almost certainly
screw up the sequencing of your state machine, and it will
quite likely send it off into the weeds.
Note that, in describing this problem, I have made no appeal
whatever to the idea of metastability. Each flip-flop
individually is behaving quite perfectly; it's just that
the collection of two flip-flops appears to behave inconsistently
because of the asynchronous input.
The problem is completely (yes, I really mean completely) solved
by registering the offending input in just one flip-flop.
The output of this resynchronising flop is then fed to your
state machine. Given that the input is asynchronous, a one-
clock delay in responding to it is unlikely to be a show-
stopper.
If you are both clever and lucky, you may be able to design
your state machine so that only one of its state bits is
affected by any input change. However, it is brain-
numbingly difficult to do this in the face of complicated
changes to the state machine as its design evolves, and
when synthesis tools are inclined to re-code state
vector values arbitrarily as an "optimisation". So it's
almost always better, in practice, to register the
asynchronous inputs before they get anywhere near your
state machine. Especially when you have multiple asynch
inputs to worry about.
Metastability is a much less likely culprit. Metastability
means that one individual flop misbehaves because its D input
changes at an inopportune moment, so that the internal
logic of the flop gets confused about whether to settle at
1 or 0. The flop's clock-to-output delay then becomes much
longer than its specified value. This effect, of course,
CAN happen on my single resynchronising flop, and CAN cause
trouble if its clock-to-output delay is thereby pushed out
to about a clock period; should this happen, the supposedly
resynchronised signal can itself appear to be asynchronous and
can therefore cause an input hazard on the state machine.
A second resynch flip-flop will dramatically reduce the risk
of this problem, at the expense of one more cycle of latency.
Figures published here by Peter Alfke and others suggest that
in your case, with a slow-ish clock and relatively infrequent
transitions of the asynchronous input, the risk of this
genuine metastability is so small that you can ignore it -
but you MUST either do the sums, or else be just a little
paranoid and add the extra flop in any case.
>2) I'm using the following VHDL code to detect a falling edge on the
>event inputs. Is there a better way?
>
>process( clk, ev1, ev2, ev3, ev4, reset)
Oh flippin' 'eck, what are you doing putting asynch
inputs into the sensitivity list of a clocked process?
> variable prev_ev1: std_logic;
> variable got_ev1: boolean;
>
> <variables for other events omitted>
>
> begin
> if (reset = '1') then -- reset the event states
> prev_ev1 := event;
> got_ev1 := false;
> elsif (rising_edge(clk)) then
> if (event = '0') then -- event signal is low
> if (prev_ev1 = '1') then
> got_ev1 := true; -- falling edge detected
> end if;
> prev_ev1 = '0'
> else
> prev_ev1 = '1';
> end if;
>
> <repeat edge detection for the other events>
>
> <process 'got_ev' flags in state machine & reset them>
> end if;
>end process;
Yeah, something like that. Don't reset the flags inside
the state machine. Reset them at the top of the clocked
process, so that they become purely combinational flags.
Effectively you've created a shift register with
an and gate sensing a change across its final stage.
It's sometimes easier to roll this edge detection
into the state machine (don't go into your "wait for fall" state
until you've detected "input high"). Depends on what you're
doing in the state machine. Once again, given that you have
multiple inputs, I suspect the scheme you outline is as good
as you'll get - and it's easy to understand.
>Any advice welcome!
Finally, please DON'T do anything that depends on
simultaneity of two or more of the external asynchronous
inputs - you simply can't rely on that, given that they
are asynchronous relative to your clock. The best you
can do is to identify when two or more inputs change
within one or two sampling clocks of each other.
Alternatively, if you're very lucky you may have an
external signal that indicates when the four inputs
are stable and therefore it's safe to sample them.
HTH
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 78407
sowjanya_sn@mindtree.com wrote:
>Hi ,
>I have general question regarding the Master Serial Programming
>mode .
>In the Master Serial Programming mode , FPGA drives the clock . But ,
>how will the FPGA know that there is relevant and complete data present
>on the PROM . Is there any mechanism to tell the FPGA that the
>configurable data is present on the PROM and FPGA to initiate the
>clock.
>
In just a few words, the FPGA doesn't know at the begining if the prom
has "relevant" (and it doesn't have to know) data it just run the clock
enable the prom (INIT->\CE) which resets the internal counter inside the
prom and the prom will start to shift out the bitstream. The FPGA will
parse the incoming bitstream to detect a valid header (0xFFAA55 not
sure if this is correct - just check the docs) and everything following
this sequence is considered bitstream for the configuration mechanism
(and will count for the CRC check)
Short: in master serial mode the fpga is assuming that the prom has the
bitstream already.
Aurash
>
>
>Thanks in Advance ,
>Sowjanya
>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 78408There is a very friendly and easy to use tool called "memory editor" and it's located in the core generator application. It will make your life alot easier... Regards, Moti.Article: 78409
"Nicholas Weaver" wrote: > Physical/corporate security is a PITA, depending on one's level of > paranoia. > > for the properly paranoid, working at home is definatly NOT allowed. I'm not sure that paranoia is involved here, but rather, reality. Yes, paranoia might be an element, but not an overwhelming one, at least in my opinion. The question I posed might be considered a mental excercise rather than a quest for a full solution. I know that the real solution would be horribly complex and constraining from just about every angle. We are talking government-grade security with threat of prison...and even that doesn't work 100% of the time. An example of reality might be hiring an offshore team for some design work. How can you even approach securing that design? I don't think that it is possible. As a small company, I must admit, from time to time there exists a concern about having valuable design data that should be private become exposed to "the elements". Not necessarily maliciously, but rather, accidentally. Example: You travel to a conference for a few days and take your laptop along to continue working on the project. You forget that you have some shares enabled. Upon plugging into the hotel's network your files are exposed to other industry folk staying at the same hotel. The ONLY experience we've had with "data migration" did not involve design files but rather a $10K CAD system software that was stolen (CD duplication) by an engineer on his way out. For a small company this is quite painful. Taking someone to court over this is both expensive and futile. What are you going to do, make the guy erase all of his copies? Impossible. Anyhow, it would be interesting to find a simple methodology to enhance design security rather than to lock down all avenues of escape. One such idea is to use a encrypted file system. www.ntfs.com has a bit of information on Windope's EFS. It seems to me that this might (and a big "might") serve to prevent simple copies of files onto various media (or transmission --hotel scenario--) from being of any use. Of course, we have to remember that we are dealing with engineers here... -MartinArticle: 78410
> >"Alex Gibson" <me@privacy.net> wrote in message >news:365ps8F4sc51gU3@individual.net... >> http://www.xilinx.com/products/spartan3/s3boards.htm#edk >> >> Is there any where to download the eval version of the edk >> if you already have a spartan3 starter kit ? >> >> Alex >> > >or to get an evaluation cd ? I did ask Xilinx about this and just got this ansver from "online store" **** Quote ***** The EDK eval is being sent to all who have purchased the Spartan 3 Starter kit and will begin shipping within the next couple of weeks. **** End Quote ***** Thank you Xilinx , for an excellent service :-) Rgds Carsten DenmarkArticle: 78411
Jim Granville wrote: > Antti Lukats wrote: > >> Hi Jim, >> >> any more about this lattice info I mean of what you can say ;) > > > Hi Antti, > > Well, this was the info released on Sept 10th : > > "In addition, Lattice has recently received the first 130nm Flash-based > products and the first 90nm products fabricated by Fujitsu, which are > currently in the early stages of evaluation." > > These are the ones comming after the already released EC/ECP FPGAs. > > Actel say Q4 for production, so there is time for Lattice to come > to the party. I'm not sure what party you are referring to. Lattice already has flash/SRAM parts that combine the best of both worlds. They are not as cheap as these however. Is that what you mean, the low priced parts? > and no serial load, you have to consume FPGA fabric to init... That pretty well sucks. I guess the cost of initializing the sram from flash was more than they felt it was worth. But it really does put a damper on the CPU core thing. Now you have to add back the external Flash. >> and that the FROM (1k flash array) is not writeable from FPGA only >> from ext JTAG > > > that's somewhat understandable. > Still, 1K is probably (just) enough to include a tiny-boot-load, so a > MUX is not needed in the critical RAM path of a SoftCPU. But you *do* need a mux in the even more critical instruction fetch path of a core CPU. These parts are also a bit light on ram. Even the A3P1000 only has a bit over 16 kBytes. > Good package ranges, but why only the smallest in MLF132 ? > ( die too large on the others ? ) That's a pretty classic issue with FGPAs. Only a few users want the larger parts in low pin count packages. Otherwise they would make low pin count parts and save the die area used for IO. -- Rick Collins rick.collins@XYarius.com Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave. 301-682-7772 Voice Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.comArticle: 78412
What are the limitations of the Eval version? Is it time limited or feature limited? Thanks. Alex Gibson wrote: > "DJ" <reconfigurablecomputing@gmail.com> wrote in message > news:1107033515.069539.84000@z14g2000cwz.googlegroups.com... > > hi all > > does anyone have a cracked copy of xilinx edk.... > > can you help me getting it..? > > > > Go buy a xilinx spartan3 starter kit and get the eval versionArticle: 78413
Hi all I have no idea regarding low level hardware. I should firgure out something about ALTERA ACEX. Question is like following. 1.Are the FPGA configuration data and the firmware different? 2.How can I extract FPGA configuration data from ALTERA ACEX to my PC? 3.How can I extract firmware in EEPROM to my PC? P.S What I want to do finally is extrating data from FPGA and EEPROM and then copy to another fresh FPGA/EEPROM.Article: 78414
Hi, There chips with the mixture of Active HIGH and Active LOW signals. Is there any pros and cons of each levels? OR it simply choice of designers / manufacturers? Thanks in advance. Regards, MuthuArticle: 78415
Symon wrote: > Hi Gabor, > I think the point is, that with tiny loads on the output, i.e. small traces, > the outputs swing very quickly to whatever voltage the current sources can > provide. This probably remains within the range of the FPGA's diff inputs, > they're very good and wide. I don't see how having 'guaranteed AC content' > makes any difference. Could you explain what you mean by that? Do you mean > enough edges, or no DC? My point is that whether you model the lines as 50 ohm transmission lines with some finite delay, or as a lumped capacitive load, you will see that a current source switched into this net provides a slew-rate limited output. The slew rate should come directly from the current value and the effective capacitance. So if you had an ideal current source that never clipped, and didn't have a DC balanced code, you would slowly integrate to one state or another and never return to the zero crossing. In the case of a voltage-limited source, the issue is how much longer does it take to reach the crossover threshold if the outputs have a 2V differential (no load case having been in one state long enough to clip the current source) than it would to reach the crossover from a 0.35V differential (nominal LVDS into 100 ohms). If the slew-rate limits you to a value that you can't accept at 480 Mbps you will need the resistors, not for termination but to limit the output voltage swing. For a true current source for example at 3.5mA going into 10 pF, you would slew at most 0.35V per nanosecond. From the data sheet specs like ISOUT NP (outputs shorted together gives 12 mA max) I would guess these "current outputs" are not true current sources, so the slew time may not be that bad. However if the output were really limited to 3.5 mA you could see that trying to slew 2V would put you out of the realm of achieving 480 Mbps. You may find that the drivers don't behave this way, but putting pads for the 100 ohm terminators (even near the source) would give you a way out if they do. > As you say, I'd certainly have to try it first, the datasheet is not clear > on the output structure. See appnote HFAN-01.0 from Maxim for an overview of > their output structure. Dunno what the Texas one looks like. > On the other hand, I'd be very nervous about doing this. Especially with an > enormous 80 pin PQFP package driving the outputs. Again, think of the > hideous leadframe. Like you say, you'd have to prototype it first. > Kolja, > You do know that you can get 8x100 resistors in two packs sized 2x1mm? Rohm, > AVX, Koa etc.. have gone to a lot of trouble to make these bits. Use them! > http://www.avx.com/docs/Catalogs/crb-crc.pdf > And fix your PCB technology, your competitors will! > Cheers, Syms. > > "Gabor" <gabor@alacron.com> wrote in message > news:1107179024.417762.98680@f14g2000cwb.googlegroups.com... > > > > > at these very short signal lengths. What I am concerned about is the > > > current mode driver characteristic as described by Gabor. > > What bothers me about leaving out terminators, especially in your case > > where you're not running 8b/10b or some other code with guaranteed > > AC content, is what happens when the output has been in one state long > > enough to generate a wide voltage spread.Article: 78416
muthusnv@rediffmail.com wrote: > There chips with the mixture of Active HIGH and Active LOW signals. Is > there any pros and cons of each levels? OR it simply choice of > designers / manufacturers? I believe for TTL there is some advantage to active low for enables and such. TTL has much better current sinks than current sources. I don't believe the advantage is as big, if any, for CMOS but may have been kept for backward compatibility reasons. -- glenArticle: 78417
<muthusnv@rediffmail.com> wrote in message news:1107206334.599924.199870@c13g2000cwb.googlegroups.com... > Hi, > There chips with the mixture of Active HIGH and Active LOW signals. > OR it simply choice of designers / manufacturers? Yes the designer can define a signal to be active High or active Low - it's his choice. However... In general P type devices switch slower than N type. This means that many devices have slightly different rise and fall times - eg the fall time 5V->0V is faster than the rise time 0V->5V. This means that if you need a fast edge for a signal (lets call it a "Ready" signal) then you use the falling edge because thats faster. Therefore its natural to define Ready = True = 0V. That makes it an Active Low signal.Article: 78418
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:ctm8dm$vib$1@gnus01.u.washington.edu... > muthusnv@rediffmail.com wrote: > > > There chips with the mixture of Active HIGH and Active LOW signals. Is > > there any pros and cons of each levels? OR it simply choice of > > designers / manufacturers? > > I believe for TTL there is some advantage to active low for > enables and such. TTL has much better current sinks than > current sources. I don't believe the advantage is as big, > if any, for CMOS but may have been kept for backward > compatibility reasons. I may be out of date but... it used to be the case that P type devices were roughly half as fast as N type. They got the edges symetrical in CMOS logic families by making the P channel FET twice the size of the N channel FET.Article: 78419
Dont fall into the trap of thinking that just because you are working with engineers they will be able to circumvent any security system,certainly there is no easy way of stopping data walking out of an office.or being e-mailed out of an office ,so you have to minimise the cost of the loss of that data or the cost of that data being known to a competitor.You could not allow your engineers to go home or use the phone or use the internat and your design would remain secure.Article: 78420
Perhaps that's why one of them ripped him off in the past... ;-) "Jezwold" <edad3000@yahoo.co.uk> wrote in message news:1107208098.133369.227150@z14g2000cwz.googlegroups.com... > You could not allow your engineers to go home or use > the phone or use the internatArticle: 78421
Gabor wrote:
> Are you saying that the synthesis uses only C-cells, or C-cells in
> addition
> to R-cells. Your fclr and fset inputs require gates, so an R-Cell
> could not
> implement the logic by itself. I think in Xilinx you would use a LUT
> as
> well as the adjacent flip-flop to implement each bit.
Well it uses ca. 4 C-cells for each bit. The 8-bit redundant register
(requiring 24 single FFs) uses 98 or 100 C-cells! It is way too
much...
In fact the Actel documentation ("Actel HDL Coding Style Guide" -
http://www.actel.com/documents/hdlcode.pdf page 87) states:
[...]
Asynchronous Preset and Clear
This is the most problematic register for the ACT 2, XL, DX, MX, SX
and ACT 3 architectures. You can only use one cell (the DFPC cell) to
design an asynchronous preset and clear register. The DFPC uses two
CMODs to form a master latch and a slave latch that together form one
register. This uses two CMODs per register and offers no logic
combinability with the SMOD. The DFPC requires more setup time and no
combinability. The net timing loss can often be as high as 10ns. Actel
recommends that you do not use any asynchronous preset and clear
registers on critical paths. Use a synchronous preset with
asynchronous clear or a synchronous clear register instead. You can
use an asynchronous preset and clear register if it does not affect a
critical path or cause high utilization in the design.
[...]
However the above contradicts to the R-cell layout shown in the
datasheet, which I've quoted in the first post - the FF in R-cell is
equipped with independent Clear and Preset.
However, when I've inspected different synthesized project, I've seen
that always one of them was tied to ground, so maybe they are not
completely indepentent?
Well, if it is impossible to build such flip-flops with the R-cells,
and if the price of RT parts is unacceptable, what are the
alternatives?
Does anybody know if there are some data about radiation hardness of
eg. Altera Hardcopy devices??? I've tried to google them, but found
almost nothing...
--
Regards, Wojtek Zabolotny
wzab@ise.pw.edu.pl
Article: 78422
Wojciech Zabolotny wrote:
> Gabor wrote:
>
> > Are you saying that the synthesis uses only C-cells, or C-cells in
> > addition
> > to R-cells. Your fclr and fset inputs require gates, so an R-Cell
> > could not
> > implement the logic by itself. I think in Xilinx you would use a
LUT
> > as
> > well as the adjacent flip-flop to implement each bit.
>
> Well it uses ca. 4 C-cells for each bit. The 8-bit redundant register
> (requiring 24 single FFs) uses 98 or 100 C-cells! It is way too
> much...
>
> In fact the Actel documentation ("Actel HDL Coding Style Guide" -
> http://www.actel.com/documents/hdlcode.pdf page 87) states:
> [...]
> Asynchronous Preset and Clear
> This is the most problematic register for the ACT 2, XL, DX, MX, SX
> and ACT 3 architectures. You can only use one cell (the DFPC cell) to
> design an asynchronous preset and clear register. The DFPC uses two
> CMODs to form a master latch and a slave latch that together form one
> register. This uses two CMODs per register and offers no logic
> combinability with the SMOD. The DFPC requires more setup time and no
> combinability. The net timing loss can often be as high as 10ns.
Actel
> recommends that you do not use any asynchronous preset and clear
> registers on critical paths. Use a synchronous preset with
> asynchronous clear or a synchronous clear register instead. You can
> use an asynchronous preset and clear register if it does not affect a
> critical path or cause high utilization in the design.
> [...]
>
> However the above contradicts to the R-cell layout shown in the
> datasheet, which I've quoted in the first post - the FF in R-cell is
> equipped with independent Clear and Preset.
> However, when I've inspected different synthesized project, I've seen
> that always one of them was tied to ground, so maybe they are not
> completely indepentent?
>
> Well, if it is impossible to build such flip-flops with the R-cells,
> and if the price of RT parts is unacceptable, what are the
> alternatives?
> Does anybody know if there are some data about radiation hardness of
> eg. Altera Hardcopy devices??? I've tried to google them, but found
> almost nothing...
>
> --
> Regards, Wojtek Zabolotny
> wzab@ise.pw.edu.pl
Don't know about Altera, but Atmel recently got into the Rad Hard
business:
http://www.atmel.com/ad/radhardfpga/default.asp?source=enews
Article: 78423muthusnv@rediffmail.com wrote: > Hi, > There chips with the mixture of Active HIGH and Active LOW signals. Is > there any pros and cons of each levels? OR it simply choice of > designers / manufacturers? > > Thanks in advance. > > Regards, > Muthu > Unconnected TTL inputs are interpreted as logic high. Hence it is more convenient to define the active level of control signals as logic low and allow the designers to simply not connect the pins carrying those signals if they don't need them. Also, if a cable is unplugged from a board the inputs read high (not active) and the board does not attempt to do anything unexpected. Active low is also commonly used for signals with multiple drivers, e.g., interrupt request lines. In this case there is a pull-up resistor and open-collector or open-drain drivers that pull the singnal low. My 2c. -- GeorgiArticle: 78424
I wrote, after being frustrated at not finding any cheap fixed 1.2V: linear regulators: > Is there any reason why using an LM317S adjustable linear regulator > with 1% resistors wouldn't be satisfactory for the Spartan 3 power > supplies, particularly Vccint and Vccaux? [I later discovered that it won't meet the spec because the reference (feedback) voltage may be as high as 1.3V. Someone else pointed me to the Sharp PQ012FZ 1.2V LDO, which is cheap but poorly documented.] Anton Erasmus <nobody@spam.prevent.net> writes: > Have you looked at the ON Semiconductor offerings ? They have quite a > few regulators, at very good prices. I use the LM1117 Series quite > often. It does not have a fixed 1.2V version, but it does have an > adjustable one as well. The National LM1117 and the On equivalent, the NCP1117, have the same problem with reference voltage. For On's part, the max is 1.27V, which is too high because the Vccint maximum is 1.26V. Admittedly this isn't out of range by much, and would probably be OK, but I prefer to stick to proper engineering practice and use parts with which I can guarantee that the specs are met. The only obvious problem with the Sharp part is that the data sheet doesn't specify the allowable characteristics of the output capacitor (minimum/maximum capacitance and ESR). For an LDO that seems fairly important. Eric
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