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
bjrosen <bjrosen@polybus.com> wrote in <93m3nr$j82$1@nnrp1.deja.com>: >The Redhat Package Manager makes sure that this doesn't happen on Linux. >When you do an install it checks all of the dependencies and tells you >what applications you are going to break. This assumes the app uses a packaging system. Some developers avoid packaging systems to remain less tied to a distribution. In many cases RPM's are provided by 3rd party packagers or a distribution vendor, not the original source of the tarball. >On Windows every installer assumes that it's free to replace anything it >wants. But that's a matter of convention, not something enforced either on Linux or Windows. Package managers can help, but they're not a panacea. A vendor can either supply only tarballs, or supply packages that are just as broken as Windows installers. (I regularly help newbie packagers of packages I'm interested in to fix their packages. A common error is to forget %config attributes in the %files list, which clobbers one's customized config files when upgrading with the next version's stock config files.) >Also on Linux you can use different libraries for every app if you want, >thats what the LD_LIBRARY_PATH env variable is for. In Windows, an app can put all its DLL's in the app directory. Why doesn't this happen? Why do so many apps insist on dropping their stuff in the system directory?Article: 28451
What's the fastest binary up-counter speed that can be wrung from a speed grade 6 Virtex? I need to emulate a few ASIC counters (one 16 bit and one 32 bit) that are presently implemented with simple chained toggle flops. These counters have async. clear only, no load/preset. Before getting to the post P&R sims and after looking at Xilinx literature, it looks like I should expect around 100 MHz. I'm looking to use the secondary interconnect lines. TIA LawrenceArticle: 28452
Jamie Sanderson wrote: > > I guess what I thought was a clear question really wasn't, since I've had a > number of responses which didn't address the issue. (not that I don't > appreciate the effort) > > I think it would be illuminating if I posted an example of Jan's code. To > keep it short, I used the polynomial from E1, which is a CRC-4 with a > generating polynomial of x^4 + x + 1, calculated over a byte. > > Looking at the code below, you'll find that it contains a set of four XOR > statements which compute successive values of the CRC. What I don't > understand is how these statements were generated. Clearly there is an > algorithm for doing this since Jan's tool obviously makes use of one. I'd > like to know what that is (assuming it's not proprietary). I don't know of resources on the web with this info (though they may well exist). The book that I found best explained going from the polynomial to XOR gates is Lin and Costello's Error Control Coding. Kind of old (1983) but still relevant. -- My real email is akamail.com@dclark (or something like that).Article: 28453
Depends! (gotta love that answer) If you can live with a ripple counter, for example, the speeds can be more than 500MHz. But then you have to deal with non-synchronous outputs. For synchronous binary counters the carry chain limits non-pipelined performance. For 16 bits in a -6, you can get about 195 MHz, but you need to be careful about fan-in on any controls. For a free running counter, the automatic tool flow should get you pretty close to that. As soon as you add controls, you'll need to be careful about fan-in and implementation to get it. You'll need to play some tricks with the 32 bit such as pipelining the carry to get the 32 bit counter running near the same rate. That said, 100 MHz is a pretty easy to hit target for a -6. I've been doing 100+ MHz DSP designs with 16-24 bit carry chains in virtex -4's. Lawrence Peregrim wrote: > > What's the fastest binary up-counter speed that can be wrung from a > speed grade 6 Virtex? I need to emulate a few ASIC counters (one 16 > bit and one 32 bit) that are presently implemented with simple chained > toggle flops. These counters have async. clear only, no load/preset. > Before getting to the post P&R sims and after looking at Xilinx literature, > it looks like I should expect around 100 MHz. I'm looking to use the > secondary interconnect lines. > > TIA > Lawrence -- -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 or http://www.fpga-guru.comArticle: 28454
Kenneth Porter wrote:
>
> bjrosen <bjrosen@polybus.com> wrote in <93m3nr$j82$1@nnrp1.deja.com>:
>
> >The Redhat Package Manager makes sure that this doesn't happen on Linux.
> >When you do an install it checks all of the dependencies and tells you
> >what applications you are going to break.
>
> This assumes the app uses a packaging system. Some developers avoid
> packaging systems to remain less tied to a distribution. In many cases
> RPM's are provided by 3rd party packagers or a distribution vendor, not the
> original source of the tarball.
But we are talking about the Alliance tools. Should Xilinx ever distribute
(hint! hint!) Linux tools, I'd expect them to be in .rpm format. I don't
mean 'expect' as in "they'd better be", I mean it in the sense "most
distributors do"
> >On Windows every installer assumes that it's free to replace anything it
> >wants.
>
> But that's a matter of convention, not something enforced either on Linux
> or Windows. Package managers can help, but they're not a panacea. A vendor
> can either supply only tarballs, or supply packages that are just as broken
> as Windows installers. (I regularly help newbie packagers of packages I'm
> interested in to fix their packages. A common error is to forget %config
> attributes in the %files list, which clobbers one's customized config files
> when upgrading with the next version's stock config files.)
>
> >Also on Linux you can use different libraries for every app if you want,
> >thats what the LD_LIBRARY_PATH env variable is for.
>
> In Windows, an app can put all its DLL's in the app directory. Why doesn't
> this happen? Why do so many apps insist on dropping their stuff in the
> system directory?
Why? Who knows. Certainly most linux apps don't have this problem.
Perhaps it's just a "typical use" thing - most Windows programmers are
used to having "wizards" to do the grunt work for them. I'd guess the
"create a package" wizard in Visual C++ defaults to stuffing everything
into the system (system32) folder.
Under Linux it's the opposite by convention - you install into /opt/<package>/{lib,bin,man,etc...} or /usr/local/<package>/...
I think the /usr/local... is no longer part of the LFS spec
though, I think /opt/<package> is the recommended layout now.
Two "absolutely safe" methods come to mind for supporting linux:
o Xilinx could install their own versions of the shared libs
they use, and use LD_LIBRARY_PATH as above, or
o They could link the programs statically.
So the 'make world' target makes 2 rpm's, one the "this is only going
to work on 99.9% of glibc systems" (the standard rpm) or the "this
will always work" (the static/own libraries rpm). End of problem.
The first "safe" case has the advantage you only need to download
the libs once, then it's a faster download for the changing code,
but frankly I wouldn't care - given the choice "You can have
statically linked binaries or nothing" I would be a happy bunny :-)
ATB,
Simon.
--
Physicists get hadrons!
Article: 28455testing -- Al Sabagh 98081-2150 Burnhamthorpe Rd W. Mississauga, ON L5L 3A0 Canada Fax: 530 504 9330 "Christof Paar" <christof@ece.wpi.edu> wrote in message news:Pine.OSF.4.10.10101121557500.3338-100000@goya.WPI.EDU... > We apologize for multiple mailings. -Christof Paar > > =================================================================== > > WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS > (CHES 2001) > > www.chesworkshop.org > > Paris - France > May 13 - 16, 2001 > > Second Call for Papers > > General Information > > The focus of this workshop is on all aspects of cryptographic > hardware and embedded system design. The workshop will be a forum of > new results from the research community as well as from the industry. > Of special interest are contributions that describe new methods for > efficient hardware implementations and high-speed software for > embedded systems, e.g., smart cards, microprocessors, DSPs, etc. We > hope that the workshop will help to fill the gap between the > cryptography research community and the application areas of > cryptography. Consequently, we encourage submission from academia, > industry, and other organizations. All submitted papers will be > reviewed. > > This will be the third CHES workshop. The first workshop, CHES '99, > was held at WPI in August of 1999 and was very well received by > academia and industry. There were 170 participants, more than half of > which were from outside the United States. The second workshop, CHES > 2000, was also held at WPI in August of 2000 and had an attendance of > 180. > > The third workshop, CHES 2001, will be held in Paris in May of 2001. > The topics of interest include but are not limited to: > > * Computer architectures for public-key cryptosystems > * Computer architectures for secret-key cryptosystems > * Reconfigurable computing and applications in cryptography > * Cryptographic processors and co-processors > * Modular and Galois field arithmetic architectures > * Tamper resistance on the chip and board level > * Smart card attacks and architectures > * Efficient algorithms for embedded processors > * Special-purpose hardware for cryptanalysis > * Fast network encryption > * True and pseudo random number generators > * Cryptography in wireless applications > > > Instructions for Authors > > Authors are invited to submit original papers. The preferred > submission form is by electronic mail to submission@chesworkshop.org. > Papers should be formatted in 12pt type and not exceed 12 pages (not > including the title page and the bibliography). The title page should > contain the author's name, address (including email address and an > indication of the corresponding author), an abstract, and a small > list of key words. Please submit the paper in Postscript or PDF. We > recommend that you generate the PS or PDF file using LaTeX, however, > MS Word is also acceptable. All submissions will be refereed. > > Only original research contributions will be considered. Submissions > must not substantially duplicate work that any of the authors have > published elsewhere or have submitted in parallel to any other > conferences or workshops that have proceedings. > > > Important Dates > > Submission Deadline: February 15th, 2001. > Acceptance Notification: March 31st, 2001. > Final Version due: April 21st, 2001. > Workshop: May 13th - 16th, 2001. > > NOTE: The CHES dates May 13th - 16th are the Sunday - Wednesday > succeeding Eurocrypt 2001 which ends on Thursday, May 10th. > > > Mailing List > > If you want to receive emails with subsequent Call for Papers and > registration information, please send a brief mail to: > mailinglist@chesworkshop.org > > > Invited Speakers > > Ross Anderson, University of Cambridge, U.K. > Protecting Embedded Systems - the Next Ten Years > > > Program Committee > > Ross Anderson, University of Cambridge, England > Jean-Sebastien Coron, Gemplus, France > Kris Gaj, George Mason University, USA > Jim Goodman, Chrysalis-ITS, Canada > Anwar Hasan, University of Waterloo, Canada > Peter Kornerup, Odense University, Denmark > Bart Preneel, Katholieke Universiteit Leuven, Belgium > Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium > Christoph Ruland, University of Siegen, Germany > Erkay Savas, cv cryptovision, Germany > Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA > Jacques Stern, Ecole Normale Superieure, France > Colin Walter, Computation Department - UMIST, U.K. > Michael Wiener, Entrust Technologies, Canada > > > Organizational Committee > > All correspondence and/or questions should be directed to either of the > Organizational Committee Members: > > Cetin Kaya Koc > (Publications Chair) > Dept. of Electrical & Computer Engineering > Oregon State University > Corvallis, Oregon 97331, USA > Phone: +1 541 737 4853 > Fax: +1 541 737 8377 > Email: Koc@ece.orst.edu > > David Naccache > (Program Chair and Local Organization) > Gemplus Card International > 34 Rue Guynemer > 92447 Issy les Moulineaux Cedex, FRANCE > Phone: +33 1 46 48 20 11 > Fax: +33 1 46 48 20 04 > Email: David.Naccache@gemplus.com > > Christof Paar > (Publicity Chair) > Dept. of Electrical & Computer Engineering > Worcester Polytechnic Institute > Worcester, MA 01609, USA > Phone: +1 508 831 5061 > Fax: +1 508 831 5491 > Email: christof@ece.wpi.edu > > > Workshop Proceedings > > The post-proceedings will be published in Springer-Verlag's Lecture > Notes in Computer Science (LNCS) series. Notice that in order to be > included in the proceedings, the authors of an accepted paper must > guarantee to present their contribution at the workshop. >Article: 28456
I want cracked Model Sim Where is it? Plz. give me.Article: 28457
ANNOUNCE: Full Circuit releases greatly enhanced 'TestBench Tool': Easily create testbenches (VHDL) with this low cost but powerful tool. AUTOMATIC Extracts entity from VHDL source and creates testbench VHDL source. Fills in signal names on tool so that all the user has to do is construct the test patterns. FAST Testbench VHDL source is not changed each time a test is revised (Test patterns are saved to a test vector file) so VHDL is only compiled once. POWERFUL Supports complex formulae for describing signal relationships. Has repeat sub section and repeat section. Text entry and plot view. Description displays in simulator as each test is executed. MODULAR Tests can be constructed in sections and test vectors built from one or all sections. FLEXIBLE Testbench source is small and simple to allow easy user enhancement. User modifications are protected from change by tool. User can modify project testbench for local changes or template testbench for global changes (i.e. adding user functions). Test vectors are not limited just to entity signals but can include variables and times. A typical use of this would be to pulse a clock line N times rather than have N vector file entries. Note that the clock line can still be a signal so the vectors can drive the clock directly at the change over for better control (i.e. use N-1 in variable). Another use could be to supply data where source is incomplete LOW COST 80 GBP (+VAT if applicable). Demo and 30 day full functional trial version available. Note requires Excel 97 or greater. SCREENSHOTS & WORKED EXAMPLE www.fullcircuit.com/TBtool.htm or www.fullcircuit.com (for site navigation menu and other items) FOR MORE INFO CONTACT Malcolm Reeves mreeves@fullcircuit.com -- Malcolm Reeves BSc CEng MIEE MIRSE, Full Circuit Ltd, Chippenham, UK (mreeves@fullcircuit.com, mreeves@fullcircuit.co.uk or mreeves@iee.org). Design Service for Analogue/Digital H/W & S/W Railway Signalling and Power electronics. More details plus freeware, Win95/98 DUN and Pspice tips, see: http://www.fullcircuit.com or http://www.fullcircuit.co.uk NEW - VHDL test bench toolArticle: 28458
Did anyone tried the LVDS pins on the 20k? I'm trying to run it @670Mhz. Anything I should now? Thanx, GabbyArticle: 28459
Contact Model Technology, www.model.com. They'll sell you a crack for a fair price. Changeun wrote: > > I want cracked Model Sim > Where is it? > Plz. give me. -- -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 or http://www.fpga-guru.comArticle: 28460
This sounds convenient, but the problem remains .... if a normal binary up counter looks like this: always @(posedge clk) count <= count +1; and we want the synthesis tool to turn this into a grey code counter for us: always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ; .... then there's going to be a big discrepency between RTL & gate-level simulation results, if our simulator checks the counter! > > What I'd like to see (and I think I suggested this to the Synplicity > guys) is an attribute or something in the synthesis tool that lets you > select gray-code or binary-code counters. > > That would be useful. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u -- ============================== William Lenihan lenihan3weNOSPAM@earthlink.net .... remove "NOSPAM" when replying ==============================Article: 28461
I do not want to sound arrogant or pretentious, but I have already described a Grey counter design ( XORing the D inputs of a binary counter) that offers the fastest, most flexible and even cheapest solution in a Virtex-like environment. Why look at anything else ? A 24-bit synchronous binary counter runs 300 MHz in Virtex-II, and the Grey addition slows this down by less than one ns per period, still over 230 MHz in a fully synchronous and non-pipelined operation. What more do we need? All that still remains is to make available the right VHDL/Verilog code. Peter Alfke ============================= Bill Lenihan wrote: > This sounds convenient, but the problem remains .... if a normal binary up > counter looks like this: > > always @(posedge clk) count <= count +1; > > and we want the synthesis tool to turn this into a grey code counter for us: > > always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ; > > .... then there's going to be a big discrepency between RTL & gate-level > simulation results, if our simulator checks the counter! > > > > > What I'd like to see (and I think I suggested this to the Synplicity > > guys) is an attribute or something in the synthesis tool that lets you > > select gray-code or binary-code counters. > > > > That would be useful. > > > > -- a > > ---------------------------- > > Andy Peters > > Sr. Electrical Engineer > > National Optical Astronomy Observatory > > 950 N Cherry Ave > > Tucson, AZ 85719 > > apeters (at) n o a o [dot] e d u > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ==============================Article: 28462
The challenge was tempting... Here is an 8-bit grey counter, coded to make
the
"algorithm" clearly understood (hopefully). It is coded in Altera HDL (or
AHDL),
but the syntax is simple enough to be decipherable by the legions of
VHDL/Verilogs
designers out there.
The code could be modified without much effort to have width determined by
parameter passing. If you take this step, please post it to the newsgroup.
The advantage of this coding is that the delay paths and bit "dependencies"
are
much closer to the conventional binary counter structure than some of the
other
algorithms mentioned in this thread. A disadvantage is that for N bits of
counter,
N x 1.5 FFs are needed. Each pair of bits in the count is treated as an
8-state
value, where the extra bit represents the current count direction for the
bit-pair.
An advantage is that the "immediate" dependencies (or logic equations) are
limited
to three input terms, rather than the entire width of the counter (as long
as you
ignore carry terms!).
Hopefully inspection of the code will be more clear than my attempts at
explanation.
-- Bob Elkind, eteam@aracnet.com
Code follows:
SUBDESIGN grey8
%
8-bit grey code counter, generalised to be extensible.
structure is a unidirectional ripple carry, similar
to conventional binary counter.
counter is up *only*, not bidirectional.
Bob Elkind, eteam@aracnet.com
%
(
clock : INPUT; -- main clock
enable : input=vcc; -- clock enable
reset : input=gnd; -- reset the puppy, default is off
out[7..0] : output; -- outputs
)
variable
up[4..1] : srffe;
temp[4..1][1..0] : node;
cry[4..0] : node;
cnt[4..1][1..0] : dffe;
begin
up[].clk = clock;
up[].ena = enable;
up[].prn = !reset;
cnt[][].clk = clock;
cnt[][].ena = enable;
cnt[][].clrn = !reset;
cry[0] = vcc;
%
The grey counter is segmented into bit pairs.
For each bit-pair, there are 4 count values, and 2 direction-of-count
values, hence 8 states.
Sequence is:
value direction carry out
0 up 0
1 up 0
3 up 0
2 up 1
2 down 0
3 down 0
1 down 0
0 down 1
This is sequence is implemented as a case statement or state machine,
for each of the bit-pair segments.
Also note that a "carry out" from the bit-pair to the next more significant
bit-pair occurs on the same "states" which produce count direction changes.
%
FOR i IN 1 to 4 GENERATE
case cnt[i][] is
when 0 =>
if up[i] then
temp[i][] = 1;
else
temp[i][] = 0;
end if;
when 1 =>
if up[i] then
temp[i][] = 3;
else
temp[i][] = 0;
end if;
when 2 =>
if up[i] then
temp[i][] = 2;
else
temp[i][] = 3;
end if;
when 3 =>
if up[i] then
temp[i][] = 2;
else
temp[i][] = 1;
end if;
end case;
if cry[i-1] then
cnt[i][].d = temp[i][];
up[i].s = (cnt[i][]==0); -- change direction to up
up[i].r = (cnt[i][]==2); -- change direction to down
cry[i] = !cnt[i][0] and (cnt[i][1] == !up[i]);
else
cnt[i][].d = cnt[i][];
up[i].s = gnd;
up[i].r = gnd;
cry[i] = gnd;
end if;
END GENERATE;
out[1..0] = cnt[1][];
out[3..2] = cnt[2][];
out[5..4] = cnt[3][];
out[7..6] = cnt[4][];
end;
Bill Lenihan wrote:
> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?
>
Article: 28463
The challenge was tempting... Here is an 8-bit grey counter, coded to make the
"algorithm" clearly understood (hopefully). It is coded in Altera HDL (or AHDL),
but the syntax is simple enough to be decipherable by the legions of VHDL/Verilogs
designers out there.
The code could be modified without much effort to have width determined by
parameter passing. If you take this step, please post it to the newsgroup.
The advantage of this coding is that the delay paths and bit "dependencies" are
much closer to the conventional binary counter structure than some of the other
algorithms mentioned in this thread. A disadvantage is that for N bits of counter,
N x 1.5 FFs are needed. Each pair of bits in the count is treated as an 8-state
value, where the extra bit represents the current count direction for the bit-pair.
An advantage is that the "immediate" dependencies (or logic equations) are limited
to three input terms, rather than the entire width of the counter (as long as you
ignore carry terms!).
Hopefully inspection of the code will be more clear than my attempts at
explanation.
-- Bob Elkind, eteam@aracnet.com
Code follows:
SUBDESIGN grey8
%
8-bit grey code counter, generalised to be extensible.
structure is a unidirectional ripple carry, similar
to conventional binary counter.
counter is up *only*, not bidirectional.
Bob Elkind, eteam@aracnet.com
%
(
clock : INPUT; -- main clock
enable : input=vcc; -- clock enable
reset : input=gnd; -- reset the puppy, default is off
out[7..0] : output; -- outputs
)
variable
up[4..1] : srffe;
temp[4..1][1..0] : node;
cry[4..0] : node;
cnt[4..1][1..0] : dffe;
begin
up[].clk = clock;
up[].ena = enable;
up[].prn = !reset;
cnt[][].clk = clock;
cnt[][].ena = enable;
cnt[][].clrn = !reset;
cry[0] = vcc;
%
The grey counter is segmented into bit pairs.
For each bit-pair, there are 4 count values, and 2 direction-of-count
values, hence 8 states.
Sequence is:
value direction carry out
0 up 0
1 up 0
3 up 0
2 up 1
2 down 0
3 down 0
1 down 0
0 down 1
This is sequence is implemented as a case statement or state machine,
for each of the bit-pair segments.
Also note that a "carry out" from the bit-pair to the next more significant
bit-pair occurs on the same "states" which produce count direction changes.
%
FOR i IN 1 to 4 GENERATE
case cnt[i][] is
when 0 =>
if up[i] then
temp[i][] = 1;
else
temp[i][] = 0;
end if;
when 1 =>
if up[i] then
temp[i][] = 3;
else
temp[i][] = 0;
end if;
when 2 =>
if up[i] then
temp[i][] = 2;
else
temp[i][] = 3;
end if;
when 3 =>
if up[i] then
temp[i][] = 2;
else
temp[i][] = 1;
end if;
end case;
if cry[i-1] then
cnt[i][].d = temp[i][];
up[i].s = (cnt[i][]==0); -- change direction to up
up[i].r = (cnt[i][]==2); -- change direction to down
cry[i] = !cnt[i][0] and (cnt[i][1] == !up[i]);
else
cnt[i][].d = cnt[i][];
up[i].s = gnd;
up[i].r = gnd;
cry[i] = gnd;
end if;
END GENERATE;
out[1..0] = cnt[1][];
out[3..2] = cnt[2][];
out[5..4] = cnt[3][];
out[7..6] = cnt[4][];
end;
Bill Lenihan wrote:
> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?
Article: 28464Changeun wrote: > I want cracked Model Sim > Where is it? > Plz. give me. This is a bit stupid. Because each license file of Model Sim can be used only for one year. You can get a free license to evaluate Package Power from Mentor Graphics (this program includes Model Sim) for 30 days. ChristophArticle: 28465
If you are looking for legitmately free CAE tools then check out the GNU EDA site which lists CAE tools that are available under the GPL. http://www.geda.seul.org In article <93ppol$olk$1@news1.kornet.net>, "Changeun" <albong@nownuri.net> wrote: > I want cracked Model Sim > Where is it? > Plz. give me. > > Sent via Deja.com http://www.deja.com/Article: 28466
Hi,
When importing a netlist (edif) from FPGA Compiler
II with ATMEL 6.0 (as a design) I get this
message:
"Unable to create instance ... of AML064 from
ATMEL - master not found"
looking inside the edif netlist file, I see the
following:
(edif ATA66Host
(edifVersion 2 0 0)
(edifLevel 0)
(keywordMap
(keywordLevel 0)
)
...
(external ATMEL
(edifLevel 0)
(technology
(numberDefinition)
)
...
(cell AML064
(cellType GENERIC)
(view Netlist_representation
(viewType NETLIST)
(interface
(port D
(direction INPUT)
)
(port C
(direction INPUT)
)
(port Q
(direction OUTPUT)
)
)
)
)
...
(library DESIGNS
(edifLevel 0)
(technology
(numberDefinition)
)
(cell ATA66Host
(cellType GENERIC)
(view Netlist_representation
(viewType NETLIST)
(interface
(port ...
....
)
(contents
(instance currState_reg_5
(viewRef Netlist_representation
(cellRef AML064
(libraryRef ATMEL)
)
)
)
...
1) Does thar error message means that the library
ATMEL wasn't found?
2) If it does, where is it? (I only found 'at40k'
library in
$ATMEL_INSTALL_DIR/lib/fpgaexp/At40k.net)
3) Looking in the tutorial for IDS 6.0 (pdf), i
found that I should have a file named at40k.syn
for synthesis. But actually I don't.
Hope someone can help me,
PP
Sent via Deja.com
http://www.deja.com/
Article: 28467Dear Gurus, I am trying to write up a little article for our college little newspaper but I am sort of a newbie at VHDL and FPGA. So I would like you gurus to explain to me: 1) what these terms means. 2) what are the tools used to do these kind of things. The terms are: a) Logical Design b) Physical Design c) Logical Verification d) Physical Verification thanks very much Sent via Deja.com http://www.deja.com/Article: 28468
Dear Gurus, I have a newbie question to ask you. What kind of Revision control tools do you use when you are working on a design? Any recommendation as to which is better? What tools are recommended for coverage analysis? What tools are recommended for formal verification What tools are recommended for timing verification, is it acceptable to conduct timing verification by embedding timing delays in a VHDL test bench? you know X <== ( Y AND Z ) AFTER 12 NS thanks in advance Sent via Deja.com http://www.deja.com/Article: 28469
In article <93n68n$c8v$1@s1.read.news.oleane.net>,
"Le Mer Michel" <michel.lemer@sta.fr> wrote:
> Hi
> The exact message is :
> # ** Warning: */APEX20k_ASYNCH_MEM SETUP High VIOLATION ON WADDR(1)
WITH
> RESPECT TO WE;
> # Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns
> # Time: 49989401 ps Iteration: 4 Instance:
> /test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a
/apexm
> em
> # ** Warning: */APEX20k_ASYNCH_MEM SETUP Low VIOLATION ON WADDR(0)
WITH
> RESPECT TO WE;
> # Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns
> # Time: 49989401 ps Iteration: 4 Instance:
> /test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a
/apexm
> em
> ....
>
> Michel Le Mer.
>
> S.K. Sharma <sanjay.kumar.sharma@philips.com> a écrit dans le
message :
> 93hoat$r9c$1@porthos.nl.uu.net...
> > Hi Michel,
> > Could you post the exact error message!
> > Thanks
> > Sanjay
> >
> > --
> > Sanjay Kumar Sharma
> > ASIC Design Engineer
> > Philips Semiconductors
> > Eindhoven, The Netherlands
> > "Le Mer Michel" <michel.lemer@sta.fr> wrote in message
> > news:93c9gj$kk4$1@s1.read.news.oleane.net...
> > > Hello
> > >
> > > I have a strange message about APEX20K_ timing violation during
> simulation
> > > despite I use the APEX 20KE family and that all the frequencies
are met
> > > according to Quartus.
> > >
> > > Any suggestions?
> > >
> > > Thanks
> > > --
> > > Michel Le Mer immeuble Cerium
> > > STA 12, square du Chene Germain
> > > 02 23 20 04 72 35510 Cesson-Sevigne
> > >
> > >
> >
> >
> >
>
>
With the small amount of information provided I'd venture to guess
that you are using the built in SRAM in an asynchronous fashion. The
static timing check should have yielded an error but did not either
because a generated clock was not properly described to Quartus or the
tool may just be incapable of detecting this error for this
configuration. I would suggest using the SRAM in its synchonous
configuration and generating the control signals for the synchronous
SRAM with the same clock as the SRAM.
Josh
--
Altera FPGA Consulting- Not ACAP Affiliated
Sent via Deja.com
http://www.deja.com/
Article: 28470In article <3A55F0E8.68DB6254@earthlink.net>, Ashok Mahadevan <ashokm1@earthlink.net> wrote: > Kenneth Porter wrote: > > > Ashok Mahadevan <ashokm1@earthlink.net> wrote in > > <3A553937.7FB8DA30@earthlink.net>: > > > > >http://home.earthlink.net/~ashokm1/max7000_isa_bus.htm > > > > Nice web page! > > Thank you!.....if only the circuit worked as nicely :o) > > > One thing that jumps out at me is that you're using different edges of IOWR > > for different registers. Why? For an active low write signal, one usually > > clocks a register on the rising edge. Your registers at 300, 301, and 303 > > are clocking on the falling edge of nIOWR. > > Okay, from what I understand about the PC/104 bus, this is how the nIOWRsignal > works with the data bus SD7-SD0: > > ------------ ------------ > nIOWR \ / > ---------- > > ----------------- > SDx -------< >------- > ----------------- > > The signals on the data bus are stable, then the nIOWR signal is asserted > for a period of time, and then brought back high. I can latch the data on > the first falling edge of nIOWR. Am I wrong here? > > As to why I am using different edges of nIOWR for the latches, it was the > only way I could get them to latch!. I tried different edges, and this > seemed to work the best. The operation is not consistent however since it > works only on one 74373 latch and not the other. I am doing something > wrong, but am unable to find out what. > > > The 245 structure looks ok. Are you running the latest Altera software? > > I thought so too, but the warnings from the Compiler and the fact that > the setup does not work unless the 74245 section is disabled leads me to > believe that it is not an accepeted form of implementing a bi- directional > bus interface. > > Has anybody implemented a 74245 in an Altera device that they would like > to share with me? I received a reply from another person who had done some > interfacing with the PC/104 bus, but he used an external 74245 chip in his > design. > > I am using the student edition 9.23 of the Altera MAX+Plus II software. > This is not the latest (I believe version 10 is), but I think it is > recent enough and in fairly common use. > > Thanks for your inputs..... > > Ashok > > I looked over your great web page and have a few comments. I did a circuit similar to this a few years back and I think made similar mistakes. lol First- Although the FPGA schematic editor leads you to belive you can draw anything and it will compile it, the reality is that the FPGA (or CPLD in this case) architecture is fixed. Its your job to draw a circuit that fits with the preexisting structure of the part. Having said that, you are best served by following synchronous design practices. Don't use the word "latch", its hurts peoples ears, use flip flops whenever possible at all costs. Latchs are used to solve messy asynch problems of which you don't have for this design. The only thing that you should be connecting to clock pins on your flip flops are clocks, not combinational circuity. Whenever that circuity glitchs as its settling in or decoding another ISA bus address, it will trigger your flops. The approach I would suggest is conencting the IOW signal to the flip flip clock ports, and then connecting your selects to the flop enable (place a DFFE). What you've done is a common mistake made when people are moving from MSI TTL part design to FPGAs. In general, use flops that have enables, feed your complex decoding into the enable, the clock into the clock port. This means you may not be able to use those TTL look-alike blocks, but who cares, those things are headed the way of the dinosaur anyway. As for your compiler message, relating to what I was saying about the FPGA architecture being fixed and all, there is no such thing as a tristate signal INTERNAL to the FPGA. The only place trisate buffers exist on the die are in the IO blocks. Now I can see that you have connected the tri cells to IO pins, but there is not direct path in the CPLD from IO cell to I/O cell, you must go through the internals of the CPLD between IO pins. So if you put 2 lcells between each pair of cross coupled tri cells, then the compiler should be able to route your design. Okay, hope this helps, good luck, and have fun! Josh -- Altera FPGA Consulting- Not ACAP Affiliated Sent via Deja.com http://www.deja.com/Article: 28471
In article <3a5310ff.10804430@news.dial.pipex.com>, eml@riverside-machines.com.NOSPAM wrote: > On Wed, 27 Dec 2000 17:52:30 GMT, Greg Neff <gregneff@my-deja.com> > wrote: > > >> - To keep the power low, the clocks for each subcircuit may be gated. > >> > > > >No, they may not be gated. Unless you know exactly what you are doing, > >and the internal architecture of the FPGA, you *must* clock all flip- > >flops directly from global clock nets. No gates. > > Remember that you can do all your gating *before* the clock buffer - > > Evan > You can do what you want but not to an unlimited degree and not without added complexity. The FPGA has a limited number of intenally generated global clock nets (e.g. 4). If you want you life to be easy, I don't recommend doing what you were suggesting with a bunch of clocks. The suggestion made earlier to use one high speed clock with enables for various lower frequecies is sound synchronous design but you will pay in power for this architecture. As far as the "if (clk3en) then ..." don't worry about this too much, the FF's have enables in general. Josh -- Altera FPA Consulting- Not ACAP Affiliated Sent via Deja.com http://www.deja.com/Article: 28472
In article <f9tl3tg228htuk39c9kdkfs9o2999ggbi9@4ax.com>, Muzaffer Kal <muzaffer@dspia.com> wrote: > On Sat, 16 Dec 2000 03:21:15 GMT, hchenry@comsoc.com wrote: > > >Dear all, > > > >Does anyone know how to make/steps conversion from FPGA gate-level > >netlist to ASIC gate-level netlist ? > > > >I'm currently triying convert Xilinx FPGA to ASIC's CMOS Technology by > >using Synopsys Design Compiler. > >But, some instance was unresolved references such OBUF , DFF ( flip- > >flop )!! > >Could anyone share your experiences with me ? > > First of let me ask you why you are trying to convert the gate level > netlist. It would be much easier to convert the RTL. Assuming that you > really want to do the gate level conversion, you have to make models > of all the cells in the netlist. Put them in a library file and > include it in your synthesis script. It can be a tedious and error > prone process. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.com > Ya, what happened to the RTL used to generate your FPGA netlist? This is the best way to do it. If you're very lucky, and the cells you're missing have direct equivalents in your ASIC library, the missing cells might be able to be replaced with a script. For example, the ASIC library probably has a buffer (OBUF) and probably has a positive edge triggered F/F without set/reset. Josh -- Altera Consulting- Not ACAP Affiliated Sent via Deja.com http://www.deja.com/Article: 28473
Hi Rob, Ya Martin is right, that's what I was going to suggest. The other suggestion I was going to make was to run everything on the high speed counter clock and use the low frequency shift register "clock" as a control signal to enable the shifter to shift. Josh In article <3a3de248@news.datacomm.ch>, "Martin Heimlicher" <heimlicher@scs.ch> wrote: > Hi Rob, > > You could implement the store registers on the counter clock. You could > sample the en signal on the counter clock and load the new value from the > shift register when you see a rising edge on en. This requires a 2 state > FSM. > > Regards, > Martin Heimlicher, Supercomputing Systems AG, Switzerland > > "rob" <rob4@xyz123abc.com> wrote in message > news:<91gtko$g7l$1@neptunium.btinternet.com>... > > Hi, > > > > I am trying to design a method of loading a number of counters > with > > a preset values stored in store registers. > > Data is clked serially clked into a shift register on the rising edge > of > > the serial clk(10 MHz) whilst the en signal is low, the serial to parallel > > converted data is then clked into store registers on the rising edge of > the > > en signal( high for min period of 50 ns) which is asynchronous to the clk > > that is clking the counters .The clk to the counters can range between 10 > > Mhz to 400 Mhz, the counters count down to 0 then are reloaded with a > preset > > value stored in the store registers. > > Any ideas how I can ensure that the no problems occur whilst new data is > > being loaded into the store registers and the counter is being reloaded? > > > > Thanks > > > > Rob > > > > > > -- Altera Consulting- Not ACAP Affiliated Sent via Deja.com http://www.deja.com/Article: 28474
strshn99@my-deja.com writes: > I am trying to write up a little article for our college little > newspaper but I am sort of a newbie at VHDL and FPGA. So I would like > you gurus to explain to me: > 1) what these terms means. > 2) what are the tools used to do these kind of things. They should be defined in the text book for your class. I'd suggest not writing an article for the college newspaper until you have at least 1/2 a clue about the subject matter. On the other hand, why should a college newspaper be different than any other newspaper? Every time I read an article in the newspaper about anything of which I happen to have first-hand knowledge, the article tends to be very inaccurate. So I suppose I should conclude that ALL articles in newspapers are very inaccurate.
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