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 Martin,
If you have opened a mysupport case, send me the SR number. We will need
your design to figure this out. Can you send me the design qar also?
Subroto Datta
Altera Corp.
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message
news:437b406c$0$12642$3b214f66@tunews.univie.ac.at...
> Any ideas what causes (or better how to avoid) the following crash:
>
> Internal Error: Sub-system: FYGR, File: fygr_list_of_labs.cpp, Line: 2934
> (atom_id1 >= 0) && (atom_id1 <= m_max_atom_id) && (atom_id2 >= 0) &&
> (atom_id2 <= m_max_atom_id)
> (Fitter pre-processing)
> Quartus II Version 5.1 Build 176 10/26/2005 SJ Web Edition
>
> Regards,
> Martin
>
Article: 91901You cannot specify the amount of hysteresis. There is "a little bit", but not adjustable. Hysteresis is like most medicines: A little bit is good, but too much is bad. Peter Alfke, XilinxArticle: 91902
I will use the Spartan-3 FG456 package, 3.3V. I thought on 33CMOS drivers as the most probable, and I will test the current of the drivers on the board. I haven't thought on termination because I have experience with buses loading on SRAM and Flash, running at 75MHz without problems (without terminations).The problem is that now I have three. In any case, if I have to consider bus terminations, should I conform with termination on the FPGA side (the internals) or shoud I reserve space on the pcb for terminations on the memory side? And which type of terminations should I tconsider in both side? Thank you for any feedback. RegardsArticle: 91903
Call For Papers
and
Call For Session Proposals
The 2006 World Congress in Computer Science,
Computer Engineering, and Applied Computing
WORLDCOMP'06
(composed of 28 Joint Conferences)
June 26-29, 2006, Las Vegas, USA
Dear Colleagues:
You are invited to submit a draft paper (see instructions below)
and/or a proposal to organize a technical session/workshop.
All accepted papers will be published in the respective
conference proceedings (included in major science citation
indexes). The names of technical session/workshop
organizers/chairs will appear on the cover of the proceedings as
Associate Editors.
The 2006 World Congress in Computer Science, Computer Engineering,
and Applied Computing (WORLDCOMP'06) is composed of the following
28 conferences (all will be held simultaneously, same location
and dates: June 26-29, 2006, USA).
o The 2006 International Conference on Parallel & Distributed
Processing Techniques & Applications (PDPTA'06)
o The 2006 International Conference on Scientific Computing
(CSC'06)
o The 2006 International Conference on Grid Computing &
Applications (GCA'06)
o The 2006 International Conference on Security & Management
(SAM'06)
o The 2006 International Conference on Artificial Intelligence
(ICAI'06)
o The 2006 International Conference on Machine Learning; Models,
Technologies & Applications (MLMTA'06)
o The 2006 International Conference on Software Engineering
Research & Practice (SERP'06)
o The 2006 International Conference on Programming Languages &
Compilers (PLC'06)
o The 2006 International Conference on Internet Computing
(ICOMP'06)
o The 2006 International Conference on Semantic Web & Web Services
(SWWS'06)
o The 2006 International Conference on Computer Design (CDES'06)
o The 2006 International Conference on Real-Time Computing
Systems & Applications (RTCOMP'06)
o The 2006 International Conference on Embedded Systems &
Applications (ESA'06)
o The 2006 International Conference on Wireless Networks (ICWN'06)
o The 2006 International Conference on Pervasive Systems &
Computing (PSC'06)
o The 2006 International Conference on Image Processing, Computer
Vision, & Pattern Recognition (IPCV'06)
o The 2006 International Conference on Computer Graphics & Virtual
Reality (CGVR'06)
o The 2006 International Conference on Modeling, Simulation &
Visualization Methods (MSV'06)
o The 2006 International Conference on Computer Games Development
(CGD'06)
o The 2006 International Conference on Frontiers in Education:
Computer Science & Computer Engineering (FECS'06)
o The 2006 International Conference on Foundations of Computer
Science (FCS'06)
o The 2006 International Conference on e-Business, Enterprise
Information Systems, e-Government, & Outsourcing (EEE'06)
o The 2006 International Conference on Data Mining (DMIN'06)
o The 2006 International Conference on Information & Knowledge
Engineering (IKE'06)
o The 2006 International Conference on Bioinformatics &
Biological Sciences (BBS'06)
o The 2006 International Conference on Computing in Nanotechnology
(CNAN'06)
o The 2006 International Conference on Engineering of Reconfigurable
Systems & Algorithms (ERSA'06)
o The 2006 International Conference on Communications in Computing
(CIC'6)
(a link to each conference's URL can be found at
http://www.world-academy-of-science.org - currently
under construction.)
GENERAL CHAIR AND COORDINATOR:
H. R. Arabnia, PhD
The University of Georgia
Department of Computer Science
415 Graduate Studies Research Center
Athens, Georgia 30602-7404, USA
Tel: (706) 542-3480
Fax: (706) 542-2966
E-mail: hra@cs.uga.edu
PURPOSE / HISTORY:
This set of joint conferences is the largest annual
gathering of researchers in computer science, computer
engineering and applied computing. Each of the 28 joint
conferences in WORLDCOMP is the premier conference for
presentation of advances in their respective fields.
The motivation is to assemble a spectrum of affiliated
research conferences into a coordinated research meeting
held in a common place at a common time. The main goal
is to provide a forum for exchange of ideas in a number
of research areas that interact. The model used to form
these annual conferences facilitates communication among
researchers in different fields of computer science,
computer engineering and applied computing. Both inward
research (core areas of computer science and engineering)
and outward research (multi-disciplinary, Inter-disciplinary,
and applications) will be covered during the conferences.
PROPOSAL FOR ORGANIZING TECHNICAL SESSIONS:
Each technical session will have at least 6 paper
presentations (from different authors). The session
chairs will be responsible for all aspects of their
sessions; including, soliciting papers, reviewing,
selecting, ... The names of session chairs will appear
as Associate Editors in the conference proceedings and
on the cover of the books.
Proposals to organize technical sessions should include
the following information: name and address (+ E-mail)
of proposer, title of session, a 100-word description of
the topic of the session, the name of the conference the
session is submitted for consideration, and a short
description on how the session will be advertised (in
most cases, session proposers solicit papers from
colleagues and researchers whose work is known to the
session proposer). Mail your proposal to H. R. Arabnia
(address is given above); E-mail submissions are preferred.
We would like to receive the proposals by December 29, 2005.
SUBMISSION OF PAPERS:
Prospective authors are invited to submit their draft
paper (about 5 to 8 pages - single space, font size of 10
to 12) to H. R. Arabnia by Feb. 20, 2006. E-mail submissions
in MS document or PDF formats are preferable (Fax or postal
submissions are also fine.) All reasonable typesetting
formats are acceptable (later, the authors of accepted
papers will be asked to follow a particular typesetting
format to prepare their papers for publication.)
The length of the Camera-Ready papers (if accepted) will
be limited to 7 (IEEE style) pages. Papers must not have
been previously published or currently submitted for
publication elsewhere. The first page of the draft paper
should include: title of the paper, name, affiliation,
postal address, E-mail address, telephone number, &
Fax number for each author. The first page should also
include the name of the author who will be presenting
the paper (if accepted) and a maximum of 5 keywords.
Also, the name of the conference that the paper is being
submitted to must be mentioned on the first page.
Papers will be evaluated for originality, significance,
clarity, and soundness. Each paper will be refereed by
two researchers in the topical area. The Camera-Ready
papers will be reviewed by one person.
MEMBERS OF PROGRAM & ORGANIZING COMMITTEES:
The Program Committee includes members of chapters
of World Academy of Science (chapters: supercomputing;
scientific computing; artificial intelligence; imaging
science; databases; simulation; software engineering;
embedded systems; internet and web technologies;
communications; computer security; and bioinformatics.)
The Program Committee for individual conferences is
currently being formed. Those interested in joining
the Program Committee should email H. R. Arabnia
(hra@cs.uga.edu) the following information:
Name, affiliation and position, complete mailing address,
email address, tel/fax numbers, a short biography
together with research interests and the name of the
conference offering to help with.
LOCATION OF CONFERENCES:
The conferences will be held in the Monte Carlo Resort
hotel, Las Vegas, Nevada, USA (with any overflows at other
near-by hotels). The Monte Carlo Resort is a mega hotel
with excellent conference facilities and over 3,000 rooms.
The hotel is minutes from the airport with 24-hour
shuttle service to and from the airport. This hotel has
many recreational attractions, including: waterfalls,
spa, pools & kiddie pools, sunning decks, Easy River
water ride, wave pool with cascades, lighted tennis
courts, health spa (with workout equipment, whirlpool,
sauna, ...), arcade virtual reality game rooms, nightly
shows, snack bars, a number of restaurants, shopping area,
bars, ... Many of these attractions are open 24 hours a
day & most are suitable for families & children. The
negotiated room rate for conference attendees is very
reasonable. The hotel is within walking distance from
most other attractions (major shopping areas, recreational
destinations, fine dining & night clubs, free street
shows, ...).
IMPORTANT DATES:
Dec. 29, 2005: Proposals for organizing/chairing sessions.
Feb. 20, 2006: Submission of papers (about 5 to 8 pages)
March 20, 2006: Notification of acceptance
April 20, 2006: Camera-Ready papers & Prereg. due
June 26-29, 2006: The 2006 World Congress in Computer Science,
Computer Engineering, and Applied Computing
(WORLDCOMP'06 - 28 joint conferences)
TOPICAL SCOPE FOR EACH CONFERENCE:
To receive the complete list of topics for each of the
28 conferences, send an email to hra@cs.uga.edu or
wait for the conferences' URL's to be constructed.
FUTURE ANNOUNCEMENTS:
If you do not wish to receive future announcements about this
event, please send an email to hra@cs.uga.edu.
Article: 91904Heiner, is your FIFO implementation synchronous (same clock for write and read) or asynchronous ( independent clocks for write and for read)? The former is simple, the latter is far more tricky. Peter Alfke, XilinxArticle: 91905
i everyone, i'm teaching a vlsi design class, and we're covering datapath this week. we use weste and harris' new edition of "cmos vlsi design". it's a great book; however, it doesn't discuss actual delays/area costs for adders, multipliers, dividers, etc., and the other sources i've looked at tend to be focused on asymptotics (O(log N) type analyses). does anyone know off the top of their heads what the actual delay/area numbers are like on a modern FGPA for the following: - addition, multiplication, division - 16/32/64 bit - number of pipeline stages for these implementations. i'd also be interested in knowing correspondnig values for floating point arithmetic, suggestions for survey articles would be welcome thanks in advance, adnanArticle: 91906
Martin wrote: <snip> > Again, it'll be interesting to watch and see what happens come the middle of > next year. > > To be on-topic. It took our very large distributor almost a month to come > up with an RoHS-compliant part number to replace a Virtex 2 we've been using > in a design for a couple of years. It surprised me that it took that much > work. and there are more escape clauses appearing, as they realise the silliness of some of this : eg from the last link "..and any lower melting temperature solder required to be used with high melting temperature solder to complete a viable electrical connection." Seems now 'viable connection' and reliable operation are being recognized - someone must have pointed out that lead-free may reduce safety ! Perhaps if you are unable to _prove_ you have a reliable/viable electrical connection ( and that includes thermal cycling stresses and fatigue failures, over time ) then these escape clauses now apply ? Amazing to see light bulbs exempt - given their short life spans, and direct waste flows, shouldn't they be first in the line ? -jgArticle: 91907
abeaujean@gillam-fei.be wrote: > No. There are no async inputs to my state machine, and only one clock. > The problem has been clearly identified as a bad behaviour of PART only > of the state machine. That part seems to pickup extra clock edges. I > still believe that the problem lies in the shape/reflection/etc.. of > the clock. The part of the state machine that fails runs (badly) on > itself, no external interaction. If you have the room, you could build another state-engine, and condition that ones clock, with anti-furr logic : that is, a Set/Reset scheme on the clock, with delay elements to prevent too rapid toggling. Then compare the two state pathways in operation ? -jgArticle: 91908
hi, does anybody know if the flash memory in these new XP devices is generally accessable from user's design? if so, how much (spare) capacity might exist outside the bitstream and whether it could be usefully used for key storage or sections of code/data? thanks ;o)Article: 91909
Jim Granville wrote: > and there are more escape clauses appearing, as they realise the silliness > of some of this While I generally agree that reduction of waste and hazardous substances is an important goal for all of us, there's this thing I call "sense of proportion" that seems to get lost when politicians and special-interest groups get ahold of ideas. Europe is perplexing to me in many ways. While I admire the fact that they got it absolutely right on so many fronts, it is amazing to me that you can't walk into a restaurant in the dozen or so cities I've been to without walking away with lung cancer. Or, that, for example, concepts of safety seem completely foreign in some areas (don't take your kid for a tour inside of a windmill in the Netherlands unless you are ready to watch'em like a hawk --no safety barriers between little hands and huge gears!). Anyhow, like I said, I think RoHS will be interesting to watch. Good concept, but hard deadlines, stiff penalties and horrendously fuzzy --and shifting-- regulations sure set the stage for a commedy...or a tragedy. Again, trying to be on topic, I guess the message is that there is no real data on the long-term consequences of converting non-trivial designs to RoHS. What approaches are large companies taking to testing such designs after conversion? Accelerated aging, mechanical robustness, signal integrity and other issues come to mind. To add to this, I've seen power supply manufacturers' eyes glaze over when RoHS is mentioned. Nobody wants to deal with this thing unless they absolutely must. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian eCinema Systems, Inc. To send private email: x@y where x = "martineu" y = "pacbell.net"Article: 91910
Don't forget to include distributed arithmetic as a space time tradeoff, which for certain applications is a substantial win after dealing with the data flow archtecture and pipelining for it.Article: 91911
Hi,
I am having problems with XST Synthesis from Xilinx. When synthesizing
a unit from my created IP, the synthesis tool just stops, providing no
error explanation. The last messages I get from the log files are the
following:
Synthesizing Unit <DEV4_uid101>.
Related source file is
//hamurabi.iro.umontreal.ca/brassaro/projet/Systeme_Test/pcores/pow_function_v1_00_a/hdl/vhdl/DEV4_uid101.vhd.
WARNING:Xst:647 - Input <u_sid88_sid1909_sid77_uid2807<0>> is never
used.
WARNING:Xst:647 - Input <u_sid79_sid1921_sid88_uid2830<0>> is never
used.
WARNING:Xst:647 - Input <u_sid88_sid1819_sid64_uid3043<0>> is never
used.
WARNING:Xst:647 - Input <u_sid88_sid1847_sid68_uid2759<0>> is never
used.
WARNING:Xst:647 - Input <u_sid88_sid1875_sid72_uid2981<0>> is never
used.
WARNING:Xst:647 - Input <u_sid88_sid76_sid1903_uid3116<0>> is never
used.
WARNING:Xst:647 - Input <u_sid88_sid78_sid1915_uid2953<0>> is never
used.
WARNING:Xst:647 - Input <u_sid1825_sid88_sid65_uid2806<0>> is never
used.
WARNING:Xst:647 - Input <u_sid88_sid73_sid1881_uid2924<0>> is never
used.
WARNING:Xst:647 - Input <u_sid71_sid88_sid1869_uid3130<0>> is never
used.
Found finite state machine <FSM_0> for signal
<S208_sid107_sid102_sid106_sid135_sid113_sid131_uid2900>.
-----------------------------------------------------------------------
| States | 12
|
| Transitions | 25
|
| Inputs | 13
|
| Outputs | 12
|
| Clock | u_sid95_sid88_sid98_uid2705 (rising_edge)
|
| Clock enable |
S122_sid103_sid2164_sid2166_sid102_sid2167_uid2961 (positive) |
| Power Up State | fsl_interface_start
|
| Encoding | automatic
|
| Implementation | automatic
|
-----------------------------------------------------------------------
Please help!!!
Thank you
Article: 91912Jim Granville wrote: > Amazing to see light bulbs exempt - given their short life spans, and > direct waste flows, shouldn't they be first in the line ? Great! I didn't know about that one! Of course, there's the biggie, namely Automotive batteries. A typical consumer electronic product with a modest PC board in it has, perhaps, a couple of grams of solder in it, and maybe half that by weight is Pb. So, maybe only one gram of lead! The product may last 5 years or so. A typical car battery has 15 - 20 **KG** of lead in it! Yes, as a rule, car batteries are recycled, but certainly in wrecks, the battery may be destroyed, with plates and acid dripping out on the ground. It doesn't take too many wrecks where a battery has been smashed to equal the lead in a whole warehouse of electronic gear! Well, I guess I'll have to figure out the Pb content of the typical light bulb. These CERTAINLY are going in the trash, too! (They probably don't even sell burned-out bulbs in Russia anymore [for surreptitious swapping by office workers, if you are wondering why there was a market for them.]) JonArticle: 91913
aholtzma@gmail.com <aholtzma@gmail.com> wrote: > Is anyone else having problems with the ISE service pack 4 installer > crashing on Linux (any flavour)? SP2 worked all right for me, but it I've tried it right now and everything went well. BTW: backticks are deprecated, use $() instead ;) -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver Unter NT gibt es keine Admins und Anwender, nur Luser. (Jonas Luster in dasr)Article: 91914
Forgot to mention that i am using EDK 6.3i.Article: 91915
Adrian Knoth wrote: > BTW: backticks are deprecated, use $() instead ;) Deprecated? Why bother? It's not like they can remove the backtick feature from the shell without breaking a bazillion existing scripts. They can have my backtick when they pry it out of my cold, dead shell scripts. :-)Article: 91916
r.kinkead@gmail.com wrote: > hi, > does anybody know if the flash memory in these new XP devices is > generally accessable from user's design? if so, how much (spare) > capacity might exist outside the bitstream and whether it could be > usefully used for key storage or sections of code/data? > thanks > ;o) The flash is not directly accessible by the FPGA logic (unless you route I/O pins to the config logic, which seems dangerous). You can reprogram the flash from the JTAG or serial/parallel interface with the FPGA running a previous download, because the SRAM is not automatically updated when the Flash is programmed. For keys that don't change, you can obviously store the key in flash as register or memory initialization values. You can also directly access the flash using the parallel programming port if the I/O pins aren't needed for normal functioning. This might ease the serialization of keys for example after the bulk of the FPGA code is already loaded. There is no indication in the user manuals that there is excess capacity in the flash beyond the bitstream.Article: 91917
On Wed, 16 Nov 2005 14:16:01 -0000, "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >For all of you that asked if we could do better on carriage we now have a >low cost option for selected EEC countries. US and New Zealand may be added >at a later date once we sorted out how duty collection would operate. >Details are on the website on the relevant product pages. > >John Adair >Enterpoint Ltd. - Home of Raggedstone1. The Low Cost XC3S400 Development >Board. >http://www.enterpoint.co.uk A tenner to the UK is still a bit steep....Article: 91918
Hello, I'm Eric and I'm an undergraduate at the University of Maryland helping out with research and am very inexperienced with this stuff. I have a question about the Xilinx ml300 board. I was wondering if there was a general ruitine or technique in which to load data into the DDR memory and display the image on the LCD screen. More specifically, I kind of understand how in theory the TFT interface interacts with the PLB logic interface, I just don't understand how to load things on the DDR memory and then change the DCR control registers to point to it. Any help, code to do this, instruction, or tips would be highly appreciated. Again I am very new to all of this and what I think I know may be also incorrect. Thanks EricArticle: 91919
Frankly, I wish I could hope this RoHS madness will somehow die away... Such nonsense. Why don't we give up using silicon (might result into too much sand in Europe and turn it into a desert...) or any metals (too many potentially injuring sharp edges ) etc. etc., I guess we all can go on. It is really good they have set their targets non-achievable. However, I would expect the right companies will somehow meet the (duly modified in the last minute) criteria... As usual, we should follow the money if we would want to know what is this all about. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 91920
The innovation is not only built in, it's engineered in. I don't believe I've seen a more embarrassing issue in a long time. Well, at least since ARM based Excalibur and Mercury were released to zero sales. Can't even read and write to dual port rams? That should be an automatic 100% correct feature. Better set your safe write and safe read parameters. Weren't dual port rams built into FPGAs around 10 years ago? Doh! From: Altera Customer Notification [mailto:announcements@altera.com] Subject: Important Update for Stratix II and Cyclone II Devices Dear customer, Altera has identified M4K memory block issues affecting Stratix(R) II and Cyclone(TM) II FPGAs. Please see below for a description of the issues and links to more information. Issue Description: Stratix II M4K Read Issue An intermittent read failure has been detected on Stratix II FPGA M4K memory blocks in dual clock dual port mode due to a software configuration error. Cyclone II M4K Write Issue A write error has been detected on Cyclone II FPGA M4K memory blocks when using dual ports and dual clocks. Action Required: If you are using Stratix II or Cyclone II devices, read the updated errata sheets on the Altera(R) web site. Stratix II FPGA Family Errata Sheet: Cyclone II FPGA Family Errata Sheet: For further information please contact your FAE or file a service request through MySupport at: ----------------------------------------------------------------------- You are receiving this notification because you have a license to use Altera's Quartus II software, Quartus II Web Edition software, or are an Altera customer. Please do not respond to this e-mail to get further information on this issue. This mailbox is not monitored by technical support. Altera Corporation, 101 Innovation Drive, San Jose, California 95134, USAArticle: 91921
Hi all,
I have a doubt in application note XAPP224.
In my application the data is to be recovered at 100 Mb/s.
Now my question is should i use a 100 Mhz clock only to clock
the PLL, to derive
CLK0 and CLK 90 OR can i use a 24 MHZ clock as a input to my
PLL to derive CLK0(100 Mhz) and CLK90(100 Mhz with 90 degree) phase
shift.
Regards,
Prav
Article: 91922> the more bells and whistles the more there is to > break and the slower it runs. In general I would agree with your observation. But I would also say that more often than not the speed of an application has more to do with the quality of the design and the code that goes into making the application, rather than its feature set. > We have HDL designer at work and using VSS it runs like > a 2 legged dog... (no offence to animal lovers) but VSS > itself checks in and out the same files in a serious > fraction of the time. With a bit of configuring Zeus is more than happy to integrate with VSS and baring problems like slow networking, the check in, check out general take fractions of a second to complete. Jussi Jumppanen Author: Zeus for Windows http://www.zeusedit.comArticle: 91923
We are working on a proect using NIOS which needs to talk to the PC Via a serial port, However we found that the core supplied by AILTERA seems to work at slow speed only even the core is runing at 50mhz, it seems that it cannot run faster than 2400baud, Any body has silmiar problems? We are trying a UART with FIFO but still struggling with it. Any ideas/ suggestion?Article: 91924
lesnleung@gmail.com wrote:
> We are working on a proect using NIOS which needs to talk to the PC Via
> a serial port, However we found that the core supplied by AILTERA seems
> to work at slow speed only even the core is runing at 50mhz, it seems
> that it cannot run faster than 2400baud, Any body has silmiar problems?
> We are trying a UART with FIFO but still struggling with it.
>
> Any ideas/ suggestion?
>
UARTs are easy. These work at 19.2k on a Spartan 2e clocked at 24MHz,
IIRC. If you want FIFOs and all that fancy stuff you'll have to add
them -- these are just basic UARTs that expect to be backed up by logic
that's just sitting around waiting for a job to do.
I'm a beginner at verilog design; apparently that means that I had
trouble remembering how to make comments...
/**********************************************************************
asyncSer.v
Description:
Various handy utility modules.
**********************************************************************/
`define IDLE_BIT 0
`define START_BIT 1
`define DATA_BIT 2
`define STOP_BIT 3
module asyncTx(clock, reset, data, write, txd, rts, empty);
parameter baudDiv = 11'd1280;
input clock;
input reset;
input [7:0] data;
input write;
output reg txd;
output reg rts;
output reg empty;
reg [7:0] shift;
reg [2:0] count;
reg [1:0] state;
reg [10:0] baud;
always @ (state) empty = state == `IDLE_BIT;
always @ (posedge reset or posedge clock)
begin
if (reset)
begin
rts <= 0;
txd <= 1;
empty <= 1;
state <= `IDLE_BIT;
baud <= baudDiv - 1;
end
else
begin
if (state != `IDLE_BIT) baud <= baud ? baud - 1 : baudDiv - 1;
case (state)
`IDLE_BIT:
if (write)
begin
state <= `START_BIT;
shift <= data;
count <= 7;
end
`START_BIT:
if (!baud)
begin
txd <= 0;
state <= `DATA_BIT;
end
`DATA_BIT:
if (!baud)
begin
txd <= shift[0];
shift <= {1'bx, shift[7:1]};
count <= count - 1;
if (!count)
begin
state <= `STOP_BIT;
end
end
`STOP_BIT:
if (!baud)
begin
txd <= 1;
state <= `IDLE_BIT;
end
endcase
end
end
endmodule
module asyncRx(clock, reset, rxd, read, data, frameError, overflow, ready);
parameter baudDiv = 7'd80;
input clock;
input reset;
input rxd;
input read;
output reg [7:0] data;
output reg frameError;
output reg overflow;
output wire ready;
reg intReady;
reg [2:0] rxdBuff; // shift register to prevent metastability
reg [2:0] count; // bit count (0-7)
reg [1:0] state; // receiver state
reg [6:0] baud; // baud rate * 16 register
reg [3:0] subBaud; // baud rate reg
wire rxdBit;
assign rxdBit = rxdBuff[2];
assign ready = intReady;
always @ (posedge reset or posedge clock)
if (reset)
begin
state <= `IDLE_BIT;
rxdBuff <= 0;
data <= 0;
count <= 7;
baud <= baudDiv - 1;
subBaud <= 15;
overflow <= 0;
intReady <= 0;
frameError <= 0;
end
else
begin
rxdBuff <= {rxdBuff[1:0], rxd}; // shift for metastability prevention
if (baud) baud <= baud - 1;
else
begin
baud <= baudDiv - 1;
if (state != `IDLE_BIT) subBaud <= subBaud - 1;
end
if (read && intReady)
begin
intReady <= 0;
frameError <= 0;
overflow <= 0;
end
case (state)
`IDLE_BIT:
if (!rxdBit)
begin
state <= `START_BIT;
subBaud <= 15;
end
`START_BIT:
begin
if (!baud && subBaud == 8)
begin
if (rxdBit)
begin
overflow <= intReady;
if (!intReady) intReady <= 1;
frameError <= 1;
state <= `IDLE_BIT;
end
end
if (!baud && subBaud == 0)
begin
state <= `DATA_BIT;
count <= 7;
end
end
`DATA_BIT:
begin
if (!baud && subBaud == 8)
begin
data <= {!rxdBit, data[7:1]};
end
if (!baud && subBaud == 0)
begin
if (count == 0)
begin
state <= `STOP_BIT;
end
count <= count - 1;
end
end
`STOP_BIT:
begin
if (!baud && subBaud == 8)
begin
if (!rxdBit)
begin
frameError <= 1;
state <= `IDLE_BIT;
end
overflow <= intReady;
if (!intReady) intReady <= 1;
end
if (!baud && subBaud == 0)
begin
state <= `IDLE_BIT;
end
end
endcase
end
endmodule
/**********************************************************************
$Log: asyncSer.v,v $
Revision 1.6 2005/02/15 18:52:26 Tim
Make transmission start immediately instead of on a bit boundary
Revision 1.5 2005/02/15 00:32:44 Tim
Add asynchronous receive capability
Revision 1.4 2004/11/30 22:51:58 Tim
Make baud rate a parameter
Revision 1.3 2004/10/19 20:51:36 Tim
Add a buffer empty indicator
Revision 1.2 2004/08/29 20:16:18 Tim
Fix some symbol incompatibility issues
Revision 1.1 2004/08/13 19:19:03 Tim
Initial revision
**********************************************************************/
/**********************************************************************
asyncSer_test.v
Description:
Test various handy utility modules.
**********************************************************************/
`timescale 1ns/100ps
module async_test_bench;
reg clock;
reg reset;
reg rxd;
reg read;
wire [7:0] data;
wire frameError, overflow, ready;
always begin
clock <= 0;
#20;
clock <= 1;
#20;
end
initial begin
$display("Starting simulation");
rxd <= 1;
reset <= 0;
#11;
reset <= 1;
#11;
reset <= 0;
// simulate a framing error in the start bit
#100
rxd <= 0;
#300
rxd <= 1;
// simulate a good byte
#50000
rxd <= 0;
#200000
rxd <= 1;
// simulate a framing error in the stop bit
#400000
rxd <= 0;
#550000
rxd <= 1;
end
asyncRx inPort(
.clock(clock),
.reset(reset),
.rxd(rxd),
.read(read),
.data(data),
.frameError(frameError),
.overflow(overflow),
.ready(ready)
);
always @ (posedge clock or posedge reset)
begin
if (reset) read <= 0;
else
begin
read <= ready && !read;
end
end
endmodule
/**********************************************************************
$Log: asyncSer_test.v,v $
Revision 1.1 2005/02/04 22:14:58 Tim
Initial revision
**********************************************************************/
##########################################################################
#
# async_test.do
#
# $Id: async_test.do,v 1.1 2005/02/07 18:50:14 Tim Exp $
# $Author: Tim $
# $Date: 2005/02/07 18:50:14 $
# $Name: $
# $Revision: 1.1 $
#
# Description:
#
# Modelsim script for async debugging
#
##########################################################################
vsim async_test_bench
restart -f
onerror {resume}
quietly WaveActivateNextPane {} 0
add wave -noupdate -format Logic /async_test_bench/clock
add wave -noupdate -format Logic /async_test_bench/reset
add wave -noupdate -format Logic /async_test_bench/rxd
add wave -noupdate -format Logic /async_test_bench/read
add wave -noupdate -format Logic /async_test_bench/data
add wave -noupdate -format Logic /async_test_bench/frameError
add wave -noupdate -format Logic /async_test_bench/overflow
add wave -noupdate -format Logic /async_test_bench/ready
add wave -noupdate -format Literal -radix hexadecimal
/async_test_bench/inPort/rxdBuff
add wave -noupdate -format Literal -radix hexadecimal
/async_test_bench/inPort/count
add wave -noupdate -format Literal -radix hexadecimal
/async_test_bench/inPort/state
add wave -noupdate -format Literal -radix hexadecimal
/async_test_bench/inPort/baud
add wave -noupdate -format Literal -radix hexadecimal
/async_test_bench/inPort/subBaud
run 5.0ms
##########################################################################
#
# $Log: async_test.do,v $
# Revision 1.1 2005/02/07 18:50:14 Tim
# Initial revision
#
# Revision 1.3 2004/12/23 19:24:03 Tim
# Make changes to match main-line async code
#
# Revision 1.2 2004/12/14 19:58:35 Tim
# test 8-bit output debug_av.v
#
# Revision 1.1 2004/12/14 17:35:58 Tim
# Initial revision
#
##########################################################################
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
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