Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 153700

Article: 153700
Subject: Re: RPMs in xilinx 13.2
From: chthon <jurgen.defurne@gmail.com>
Date: Wed, 25 Apr 2012 23:57:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, April 9, 2012 10:53:38 AM UTC+2, salimbaba wrote:
> Hi,
> I am using xilinx 13.2 for synthesis and implementation of my design. I
> wanted to create RPMs of some small logic so that I can reuse it anywhere
> in my design by just instantiating. But I cannot find any relevant
> documentation on the internet, and the documentation I found is for
> previous versions using the floorplan method. Can anyone direct me to a
> proper documentation or some guide or link, that would be great.
>=20
> Also, when I create RPMs and I map the components by hand, whenever i wil=
l
> instantiate it, the components will be placed in the same order or will
> they change depending on the complete design and routing?
>=20
>=20
>=20
> Regards
> Muhammad Hassan	  =20
> 				=09
> ---------------------------------------	=09
> Posted through http://www.FPGARelated.com

Hi,

It seems that you are stuck with the same problem as I have. There do not s=
eem to many people here who have knowledge about hard macros and such.

Two links that are interesting:

http://www.mn.uio.no/ifi/english/research/projects/cosrecos/publications/pa=
per/recosoc11beckhoff.html

http://classes.soe.ucsc.edu/cmpe225/Fall01/hardmacro.html

It seems that the design flow should be basically this:

- Write your component in VHDL
- Synthesize it for your FPGA
- Go to PlanAhead
- Define a PBLOCK for your component, so that you can constrain it in a sma=
ll area
- Let ISE implement the design
- Go to FPGA Editor in Post-Map and Route
- Save your design first as a hard macro
! Make sure that you have a backup of this, because FPGA Editor has no undo=
 function
- Follow the instructions in the second link given

Since FPGA Editor works on large field, zooming in and out is very often ne=
cessary, and markers are very small, tiny even.

E.g. 3. A green dot will appear over pin on the CLB/slice that had previous=
ly been routed to that pad. Now, add an External Macro pin to this site; th=
is will allow the pin to be instantiated in your code. (Note that if the IO=
B was routed to two pins on a slice, you must give both pins a different na=
me, or PAR will issue errors.)=20

You will see this green dot only when you zoom in on really deep on the sli=
ce where the connection was.

This is currently how far I got (yesterday evening). The paper by Beckhoff =
and Koch is well written, but understanding will only grow by using the too=
ls.

Regards,

Jurgen

Article: 153701
Subject: Re: RPMs in xilinx 13.2
From: "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com>
Date: Thu, 26 Apr 2012 02:37:31 -0500
Links: << >>  << T >>  << A >>

Thanks a lot. But my problem got solved, I played around with RLOCs and of
course people helped me a lot. I have made a small guide for making RPMs in
verilog. If you want it maybe I can send it to you.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153702
Subject: No bitstream generation on ISE 13.4 evaluation license
From: etantonio <postmaster@etantonio.it>
Date: Thu, 26 Apr 2012 01:44:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Good morning,
I downloaded ISE 13.4 from Xilinx and installed on my pc to test an
old Spartan 3A DSP 1800  Board,
I installed an evaluation licence of 30 days, that I think includes
bitstream beneration but I have the following error:

WARNING:Bitgen:26 - Bitgen only supports DRC but not bitstream
generation on
   this device.  This condition can occur if there are problems
obtaining a
   license to run bitgen or if the design targets a device which is
Early
   Access.

Can anybody help me to solve this problem?
Thanks

ANtonio
www.etantonio.it

Article: 153703
Subject: Re: RPMs in xilinx 13.2
From: chthon <jurgen.defurne@gmail.com>
Date: Thu, 26 Apr 2012 02:26:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, April 26, 2012 9:37:31 AM UTC+2, salimbaba wrote:
> Thanks a lot. But my problem got solved, I played around with RLOCs and of
> course people helped me a lot. I have made a small guide for making RPMs in
> verilog. If you want it maybe I can send it to you.	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

You probably got more help through FPGARelated? Think I should join there too.

Even though we program in VHDL here, I gladly accept your offer. Send it to jurgen dot defurne at telenet dot be (replace where appropriate). Anything that can help with understanding the issues is welcomed.

Regards,

Jurgen

Article: 153704
Subject: Re: No bitstream generation on ISE 13.4 evaluation license
From: chthon <jurgen.defurne@gmail.com>
Date: Thu, 26 Apr 2012 04:07:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, April 26, 2012 10:44:58 AM UTC+2, etantonio wrote:
> Good morning,
> I downloaded ISE 13.4 from Xilinx and installed on my pc to test an
> old Spartan 3A DSP 1800  Board,
> I installed an evaluation licence of 30 days, that I think includes
> bitstream beneration but I have the following error:
> 
> WARNING:Bitgen:26 - Bitgen only supports DRC but not bitstream
> generation on
>    this device.  This condition can occur if there are problems
> obtaining a
>    license to run bitgen or if the design targets a device which is
> Early
>    Access.
> 
> Can anybody help me to solve this problem?
> Thanks
> 
> ANtonio
> www.etantonio.it

Is it not possible to just use the standard ISE Webpack free license? I think the Spartan 3A DSP is supported in there.

Regards,

Jurgen

Article: 153705
Subject: Re: No bitstream generation on ISE 13.4 evaluation license
From: etantonio <postmaster@etantonio.it>
Date: Thu, 26 Apr 2012 05:18:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
Yes,
it works,
thanks
Antoino


On 26 Apr, 13:07, chthon <jurgen.defu...@gmail.com> wrote:
> On Thursday, April 26, 2012 10:44:58 AM UTC+2, etantonio wrote:
> > Good morning,
> > I downloaded ISE 13.4 from Xilinx and installed on my pc to test an
> > old Spartan 3A DSP 1800 =A0Board,
> > I installed an evaluation licence of 30 days, that I think includes
> > bitstream beneration but I have the following error:
>
> > WARNING:Bitgen:26 - Bitgen only supports DRC but not bitstream
> > generation on
> > =A0 =A0this device. =A0This condition can occur if there are problems
> > obtaining a
> > =A0 =A0license to run bitgen or if the design targets a device which is
> > Early
> > =A0 =A0Access.
>
> > Can anybody help me to solve this problem?
> > Thanks
>
> > ANtonio
> >www.etantonio.it
>
> Is it not possible to just use the standard ISE Webpack free license? I t=
hink the Spartan 3A DSP is supported in there.
>
> Regards,
>
> Jurgen


Article: 153706
Subject: Platform Cable USB II in Windows 7 not Found (ISE 13.4)
From: etantonio <postmaster@etantonio.it>
Date: Fri, 27 Apr 2012 01:52:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Good morning,
it is the first time I use a XILINX Platform Cable USB II together
with Windows 7 ,
the problem is that the cable is not recognized and I've always the
answer:
"   WARNING:iMPACT - The cable selected is not avaliable, please
select a different one.
    Connecting to cable (Usb Port - USB21).
     Checking cable driver.
      Driver file xusb_xp2.sys found.
      Driver version: src=2301, dest=2301.
      Driver windrvr6.sys version = 10.2.1.0.Cable connection failed.
"
the board I want to program is the Spartan 3A DSP 1800A but I don't
think is a board problem,
simply the cable is not recognized from windows 7.
I'm using Impact 13.4 (nt64) version 0.87 XD

How can I solve this problem?
Thanks for your help

Antonio
www.etantonio.it

Article: 153707
Subject: Re: Platform Cable USB II in Windows 7 not Found (ISE 13.4)
From: Claude Sylvain <csylvain@electro-technica.com>
Date: Sat, 28 Apr 2012 09:41:23 -0400
Links: << >>  << T >>  << A >>

Hello Antonio,


On 2012-04-27 04:52, etantonio wrote:

 >
 > Good morning,
 > it is the first time I use a XILINX Platform Cable USB II together
 > with Windows 7 ,
 > the problem is that the cable is not recognized and I've always the
 > answer:
 > "   WARNING:iMPACT - The cable selected is not avaliable, please
 > select a different one.
 >      Connecting to cable (Usb Port - USB21).
 >       Checking cable driver.
 >        Driver file xusb_xp2.sys found.
 >        Driver version: src=2301, dest=2301.
 >        Driver windrvr6.sys version = 10.2.1.0.Cable connection failed.
 > "
 > the board I want to program is the Spartan 3A DSP 1800A but I don't
 > think is a board problem,
 > simply the cable is not recognized from windows 7.
 > I'm using Impact 13.4 (nt64) version 0.87 XD
 >
 > How can I solve this problem?
 > Thanks for your help
 >

- I use a "Platform Cable USB II" on a Windows 7 Professional
   64-bit computer; and all is working correctly.

- Take a look at Xilinx support:

  http://www.xilinx.com/support/#nav=sd-nav-link-182711&tab=tab-sd

- I found 1 interesting "Answer" that seems to match your
   problem.  See the link below:

http://www.xilinx.com/support/answers/41442.htm


Regards,

Claude




--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Article: 153708
Subject: Re: Platform Cable USB II in Windows 7 not Found (ISE 13.4)
From: etantonio <postmaster@etantonio.it>
Date: Sat, 28 Apr 2012 07:47:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks for your answer,

fortunately I found the solution and seems to be similar to the one
you suggest to me.


http://www.xilinx.com/support/answers/35924.htm

that is necessary only for
"Installation of Cable Drivers for ISE 10.1, 11.x on Windows 7"
hope this will be useful for someone.


Thanks, bye


Antonio D'Ottavio

www.etantonio.it

Article: 153709
Subject: Re: VHDL syntheses timestamp
From: johnp <jprovidenza@yahoo.com>
Date: Sat, 28 Apr 2012 08:28:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, April 22, 2012 2:09:44 AM UTC-7, Enes Erdin wrote:
> On Sunday, April 22, 2012 11:36:05 AM UTC+3, Arne Pagel wrote:
> > thanks for you hint,
> >=20
> >  > The bad news is that this can't be done in native VHDL.
> >=20
> > I have suspected something like that.
> >=20
> >  > Modify your (probably TCL) build scripts to parse this file and call=
 a
> >  > program to patch in a new value for the constant before the file get=
s
> >  > compiled.  Any scripting language would do; I use Perl for this.
> >=20
> > For my embedded C projects I do some similar stuff, I patch a version a=
nd date structure to the=20
> > binary output after compiling.
> > So modifying a vhdl file with the needed information would not be the p=
roblem for me.
> > Currently I am still using the ISE GUI, but I couldn't find any option =
to run custom a pre-build=20
> > command.
> > I am not sure that I am experienced enough with the build process to dr=
op the GUI since I am using=20
> > some IP cores and other GUI settings for my design.
> >=20
> > Is there any option to use still the GUI but run some customized progra=
ms at some point?
> > Maybe be adding some lines to some tcl script somewhere?
> >=20
> > On the other hand I would be very attractive to have more control over =
the vhdl build since I always=20
> > have some problems determining the files which I should put under subve=
rsion revision control.
> >=20
> > regards
> >    Arne
>=20
> In the past I did something similar (a date stamp not a time stamp) to th=
is but I was running it manually. I wrote a matlab code and I was running i=
t with octave through a batch file via scheduled tasks, many times in a day=
. But later on I gave up using it because following a synthesis with date s=
tamp was not so good for me besides it was confusing. I went on with a manu=
al version and an automatic build number.=20
>=20
> All levels of synthesis in ISE can be run with TCL scripts so instead of =
using ISE GUI you can run your synthesis with a script file, there are many=
 tutorials for doing this.
>=20
> Also in order to add a build number to your design simply you will write =
a function doing file read operation from a build file, increment it and wr=
ite back again to that file and you will assign the return of the function =
(your build number) to your signal like :=20
>=20
> signal build_no : std_logic_vector(15 downto 0) :=3D MyBuildNumberFunctio=
n;
>=20
> Assume that this assignment is done in a build.vhd file, at every synthes=
is build no will increase.

I use a Perl script to update a Verilog parameter.  You could do a similar =
thing with VHDL.  I manually run the script when I want to embed the curren=
t Unix data/time value.

It's not automated, but it does the job for me.

John P

Article: 153710
Subject: Re: FPGA acceleration v.s. GPU acceleration
From: "Dr. Beau Webber" <j.b.w.webber@kent.ac.uk>
Date: Sat, 28 Apr 2012 10:42:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, 14 September 2011 04:50:39 UTC+1, vcar  wrote:
> If I choose FPGA co-processing, the algorithm will be specifically
> optimized and R&D time will be very noticeable. If I choose GPU plan,
> algorithm migration will cost little time(even the original one is
> Matlab code), and the acceleration performance will also be quite
> well.
>=20
> As a conclusion, the FPGA acceleration only suits some certain and
> fixed application. However in the real world , many projects and many
> algorithms are very uncertain and arbitrary. With same power
> consumption, GPU plan  may lead better results. For a concrete
> project, I will consider GPU or DSP, and FPGA at last.
>=20
> Do everybody agree?

As an exercise I have recently written a USB interfaced FPGA based accelera=
tor for a simple scientific algorithm (Binning) - the original code was wri=
tten in Apl, and for large data sets (5 million) the FPGA did better than A=
pl or compiled C. It also needs testing with more of the complete algorithm=
 moved into the FPGA, so there is less USB overhead. I have not yet done a =
comparison with a GPU.
There is a video of this working and being tested on YouTube : http://www.y=
outube.com/user/LabToolsInstruments
and a fuller description of the FPGA techniques used on the Farnell Element=
14 site :=20
FPGA Modular Firmware Skeleton for multiple instruments - Morph-IC-II, YouT=
ube videos.
http://www.element14.com/community/groups/fpga-group/blog/2012/04/28/fpga-m=
odular-firmware-skeleton-for-multiple-instruments--morph-ic-ii-youtube-vide=
os

Article: 153711
Subject: FPGA Modular Firmware Skeleton for multiple instruments -
From: "Dr. Beau Webber" <j.b.w.webber@kent.ac.uk>
Date: Sat, 28 Apr 2012 11:26:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
If you have an interest in using FPGAs for the design of instruments, this may be of interest :
 
I have developed the following design as the framework for the bus interface of USB2 interfaced FPGA based instruments.
 
This firmware in intended to aid the design of instrumentation using the Morph-IC-II module and other fpga systems interfaced to the USB2 bus using FTDI's FT2232H interface chip.
 
It has been in use in prototype form in my NMR laboratory as the heart of a number of instruments (contributing to a number of papers), and would I believe aid the design of other FPGA based instrumentation.

There are some videos of this working and being tested on YouTube : http://www.youtube.com/user/LabToolsInstruments 
and a fuller description of the FPGA techniques used on the Farnell Element14 site : 
http://www.element14.com/community/groups/fpga-group/blog/2012/04/28/fpga-modular-firmware-skeleton-for-multiple-instruments--morph-ic-ii-youtube-videos

More instruments based on this VHDL code are coming out of the prototype stage and there will be information on them at http://www.lab-tools.com/instrumentation/ 
cheers,
   Beau Webber

Article: 153712
Subject: Smallest GPL UART
From: Giuseppe Marullo <giuseppe.marullonospam@iname.com>
Date: Sun, 29 Apr 2012 20:04:23 +0200
Links: << >>  << T >>  << A >>
Hi all,
I am searching for the smallest/simpler UART in verilog. I need to 
release the project under GPL and still confused about what are my options.

I would go with micro UART by Jeung Joon Lee but I am unable to 
determine its license.

There are others, like osvudu by Timothy Goddard seems released under 
(a) MIT license, thus compatible with GPL.

I need very simple stuff:

baud rate 9600-115200 with a clock of about 100MHz but should be able to 
run with other clocks, like 12MHz. No buffers and other fancy stuff.

8N1, and possibility (I need some) to have rtx, tx and rx only 
capability (I would like to instantiate just the parts I need).

Don't know if I need fullduplex, possibly yes.

What would you advice to use?

Thanks in advance.

Giuseppe Marullo

Article: 153713
Subject: Re: Smallest GPL UART
From: "Andy Bartlett" <andyb@nospamming.net>
Date: Sun, 29 Apr 2012 19:18:24 +0100
Links: << >>  << T >>  << A >>

"Giuseppe Marullo" <giuseppe.marullonospam@iname.com> wrote in message 
news:jnjvra$1fa$1@speranza.aioe.org...
> Hi all,
> I am searching for the smallest/simpler UART in verilog. I need to release 
> the project under GPL and still confused about what are my options.
>
> I would go with micro UART by Jeung Joon Lee but I am unable to determine 
> its license.
>
> There are others, like osvudu by Timothy Goddard seems released under (a) 
> MIT license, thus compatible with GPL.
>
> I need very simple stuff:
>
> baud rate 9600-115200 with a clock of about 100MHz but should be able to 
> run with other clocks, like 12MHz. No buffers and other fancy stuff.
>
> 8N1, and possibility (I need some) to have rtx, tx and rx only capability 
> (I would like to instantiate just the parts I need).
>
> Don't know if I need fullduplex, possibly yes.
>
> What would you advice to use?
>
> Thanks in advance.
>
> Giuseppe Marullo



Why not roll your own? For the simple case you have specified it will take 
less than half a day and the ip is all yours.

I'm am constantly amazed by people scratching around for cheap or free ip 
when it would actually be quicker and more efficient to DIY!

Andy 



Article: 153714
Subject: Re: FPGA acceleration v.s. GPU acceleration
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 29 Apr 2012 21:47:59 +0200
Links: << >>  << T >>  << A >>
Dr. Beau Webber wrote:
> 
> As an exercise I have recently written a USB interfaced FPGA based accelerator for a simple scientific algorithm (Binning) - the original code was written in Apl, and for large data sets (5 million) the FPGA did better than Apl or compiled C. It also needs testing with more of the complete algorithm moved into the FPGA, so there is less USB overhead. I have not yet done a comparison with a GPU.
> There is a video of this working and being tested on YouTube : http://www.youtube.com/user/LabToolsInstruments
> and a fuller description of the FPGA techniques used on the Farnell Element14 site : 
> FPGA Modular Firmware Skeleton for multiple instruments - Morph-IC-II, YouTube videos.
> http://www.element14.com/community/groups/fpga-group/blog/2012/04/28/fpga-modular-firmware-skeleton-for-multiple-instruments--morph-ic-ii-youtube-videos

I'm sure such a binning algorithm can be many times faster with a GPU,
because it is easy to parallelize it, e.g. partitioning the input data
in as many blocks as you have parallel processing units, each with its
own result sum array, and finally summing all result arrays.

I've used CUDA for magnet field calculation and it was at least 20 times
faster (depending on the graphics card)

http://www.frank-buss.de/magnetfeld/

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 153715
Subject: Re: Smallest GPL UART
From: Giuseppe Marullo <giuseppe.marullonospam@iname.com>
Date: Sun, 29 Apr 2012 23:00:45 +0200
Links: << >>  << T >>  << A >>
> Why not roll your own? For the simple case you have specified it will take

Thank you Andy, but I need to concentrate on other things, I would pass 
on serial stuff if I can this time.

Giuseppe Marullo




Article: 153716
Subject: Tabula's fpga
From: ippisl <ippisl@gmail.com>
Date: Sun, 29 Apr 2012 15:29:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
does anybody here worked or know someone that worked with the tabula
fpga device ?

Are they much more efficient than competing fpga's ?


Article: 153717
Subject: Re: Smallest GPL UART
From: Tim Wescott <tim@seemywebsite.com>
Date: Sun, 29 Apr 2012 17:37:50 -0500
Links: << >>  << T >>  << A >>
On Sun, 29 Apr 2012 19:18:24 +0100, Andy Bartlett wrote:

> "Giuseppe Marullo" <giuseppe.marullonospam@iname.com> wrote in message
> news:jnjvra$1fa$1@speranza.aioe.org...
>> Hi all,
>> I am searching for the smallest/simpler UART in verilog. I need to
>> release the project under GPL and still confused about what are my
>> options.
>>
>> I would go with micro UART by Jeung Joon Lee but I am unable to
>> determine its license.
>>
>> There are others, like osvudu by Timothy Goddard seems released under
>> (a) MIT license, thus compatible with GPL.
>>
>> I need very simple stuff:
>>
>> baud rate 9600-115200 with a clock of about 100MHz but should be able
>> to run with other clocks, like 12MHz. No buffers and other fancy stuff.
>>
>> 8N1, and possibility (I need some) to have rtx, tx and rx only
>> capability (I would like to instantiate just the parts I need).
>>
>> Don't know if I need fullduplex, possibly yes.
>>
>> What would you advice to use?
>>
>> Thanks in advance.
>>
>> Giuseppe Marullo
> 
> 
> 
> Why not roll your own? For the simple case you have specified it will
> take less than half a day and the ip is all yours.
> 
> I'm am constantly amazed by people scratching around for cheap or free
> ip when it would actually be quicker and more efficient to DIY!
> 
> Andy

I second that.  I only an FPGA hacker, and yet an NSUART (not-so 
universal asynchronous receiver transmitter) is a fairly easy proposition.

In fact: here:  One serial interface.  Easy, simple, and as an added 
bonus, free of any confusing comments.  I'm pretty sure this was for a 
25MHz clock and a baud rate of 9600 -- but, since it lacks those comments 
that might mislead, you'll have to figure that out yourself:

`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



-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 153718
Subject: Re: Smallest GPL UART
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 30 Apr 2012 00:22:50 GMT
Links: << >>  << T >>  << A >>
Giuseppe Marullo <giuseppe.marullonospam@iname.com> wrote:

>Hi all,
>I am searching for the smallest/simpler UART in verilog. I need to 
>release the project under GPL and still confused about what are my options.
>
>I would go with micro UART by Jeung Joon Lee but I am unable to 
>determine its license.
>
>There are others, like osvudu by Timothy Goddard seems released under 
>(a) MIT license, thus compatible with GPL.
>
>I need very simple stuff:
>
>baud rate 9600-115200 with a clock of about 100MHz but should be able to 
>run with other clocks, like 12MHz. No buffers and other fancy stuff.
>
>8N1, and possibility (I need some) to have rtx, tx and rx only 
>capability (I would like to instantiate just the parts I need).
>
>Don't know if I need fullduplex, possibly yes.
>
>What would you advice to use?

There is a very simple UART packed togethet with Xilinx's KCPSM. I
agree with the others. Open Source UARTs are not always the best
solution. I once used the 16550 UART from opencores but it is pretty
crappy. Very slow due to an overly complex design.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153719
Subject: Re: Smallest GPL UART
From: Frank Buss <fb@frank-buss.de>
Date: Mon, 30 Apr 2012 07:58:17 +0200
Links: << >>  << T >>  << A >>
Giuseppe Marullo wrote:

> I am searching for the smallest/simpler UART in verilog. I need to
> release the project under GPL and still confused about what are my options.

This was one of my first projects for learning VHDL:

http://www.frank-buss.de/vhdl/spartan3e.html

Most programs can use VHDL and Verilog, so I guess you could integrate
it in your Verilog project. I released it under the BSD License, so do
whatever you want with it, but mention me as an author.

You should add a (clocked) input latch to the rx signal for the
receiver, to avoid metastability problems. Something I learned the hard
way years ago, by searching mysterious and rare occuring events, which
resulted in invalid state machine states.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 153720
Subject: Re: Smallest GPL UART
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 30 Apr 2012 12:17:28 -0500
Links: << >>  << T >>  << A >>
On Mon, 30 Apr 2012 00:22:50 +0000, Nico Coesel wrote:

> Giuseppe Marullo <giuseppe.marullonospam@iname.com> wrote:
> 
>>Hi all,
>>I am searching for the smallest/simpler UART in verilog. I need to
>>release the project under GPL and still confused about what are my
>>options.
>>
>>I would go with micro UART by Jeung Joon Lee but I am unable to
>>determine its license.
>>
>>There are others, like osvudu by Timothy Goddard seems released under
>>(a) MIT license, thus compatible with GPL.
>>
>>I need very simple stuff:
>>
>>baud rate 9600-115200 with a clock of about 100MHz but should be able to
>>run with other clocks, like 12MHz. No buffers and other fancy stuff.
>>
>>8N1, and possibility (I need some) to have rtx, tx and rx only
>>capability (I would like to instantiate just the parts I need).
>>
>>Don't know if I need fullduplex, possibly yes.
>>
>>What would you advice to use?
> 
> There is a very simple UART packed togethet with Xilinx's KCPSM. I agree
> with the others. Open Source UARTs are not always the best solution. I
> once used the 16550 UART from opencores but it is pretty crappy. Very
> slow due to an overly complex design.

A design that did a good job of emulating the 16550 would have to be a 
lot more complex than just a good asynchronous receiver-transmitter. 
pair.  Particularly if you can hard-code the division ratio, bit count, 
etc., they are easy-peasy thing to write.

Certainly "overly complex" if you just need a serial interface -- but 
maybe not so if you must have compatibility with existing software.

(Note: I don't know at what point in the process one loses the 
"universal" moniker -- but hard-coding all the bits that are normally 
software programmable would seem to be it).

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 153721
Subject: Re: Smallest GPL UART
From: Jan Coombs <jan_2011-02@murray-microft.co.uk>
Date: Mon, 30 Apr 2012 21:50:24 +0100
Links: << >>  << T >>  << A >>
On 29/04/12 19:04, Giuseppe Marullo wrote:
> Hi all,
> I am searching for the smallest/simpler UART in verilog. I need to
> release the project under GPL and still confused about what are my
> options.

I have just completed a very simple UART model to communicate with 
a FPGA dev board.

The package has been tested with an integrated test harness which 
runs Tx & Rx back to back. Also tested in real hardware with a 
CP2102 USB to serial adapter.

Requirements: Python with MyHDL package, see  http://myhdl.org
Exports: VHDL or Verilog

Jan Coombs
-- 
(email valid at present)

Article: 153722
Subject: Re: Smallest GPL UART
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 30 Apr 2012 21:28:08 GMT
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:

>On Mon, 30 Apr 2012 00:22:50 +0000, Nico Coesel wrote:
>
>> Giuseppe Marullo <giuseppe.marullonospam@iname.com> wrote:
>> 
>>>Hi all,
>>>I am searching for the smallest/simpler UART in verilog. I need to
>>>release the project under GPL and still confused about what are my
>>>options.
>>>
>>>I would go with micro UART by Jeung Joon Lee but I am unable to
>>>determine its license.
>>>
>>>There are others, like osvudu by Timothy Goddard seems released under
>>>(a) MIT license, thus compatible with GPL.
>>>
>>>I need very simple stuff:
>>>
>>>baud rate 9600-115200 with a clock of about 100MHz but should be able to
>>>run with other clocks, like 12MHz. No buffers and other fancy stuff.
>>>
>>>8N1, and possibility (I need some) to have rtx, tx and rx only
>>>capability (I would like to instantiate just the parts I need).
>>>
>>>Don't know if I need fullduplex, possibly yes.
>>>
>>>What would you advice to use?
>> 
>> There is a very simple UART packed togethet with Xilinx's KCPSM. I agree
>> with the others. Open Source UARTs are not always the best solution. I
>> once used the 16550 UART from opencores but it is pretty crappy. Very
>> slow due to an overly complex design.
>
>A design that did a good job of emulating the 16550 would have to be a 
>lot more complex than just a good asynchronous receiver-transmitter. 
>pair.  Particularly if you can hard-code the division ratio, bit count, 
>etc., they are easy-peasy thing to write.
>
>Certainly "overly complex" if you just need a serial interface -- but 
>maybe not so if you must have compatibility with existing software.

I designed a 16550 clone before and trust me: it was waaaaaaaaaay more
simple and faster than the one from Opencores. The one I designed is
running in over 10.000 products 24/7. The thing is that you can't take
designs from one employer to the other.

Where the Opencores design failes is using two clocks and asynchronous
FIFOs. Besides that the I/O for the registers is also asynchronous
while it doesn't need to be.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153723
Subject: Re: Smallest GPL UART
From: Giuseppe Marullo <giuseppe.marullonospam@iname.com>
Date: Tue, 01 May 2012 01:47:17 +0200
Links: << >>  << T >>  << A >>
Jan, Frank, Tim, Nico and Andy,
many thanks for your answer. I would like to stick with Verilog, at the 
moment I am trying with the following code:

// Documented Verilog UART
// Copyright (C) 2010 Timothy Goddard (tim@goddard.net.nz)
// Distributed under the MIT licence.
//
// Permission is hereby granted, free of charge, to any person obtaining 
a copy
// of this software and associated documentation files (the "Software"), 
to deal
// in the Software without restriction, including without limitation the 
rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be 
included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
// THE SOFTWARE.
//
module uart(
     input clk, // The master clock for this module
     input rst, // Synchronous reset.
     input rx, // Incoming serial line
     output tx, // Outgoing serial line
     input transmit, // Signal to transmit
     input [7:0] tx_byte, // Byte to transmit
     output received, // Indicated that a byte has been received.
     output [7:0] rx_byte, // Byte received
     output is_receiving, // Low when receive line is idle.
     output is_transmitting, // Low when transmit line is idle.
     output recv_error // Indicates error in receiving packet.
     );

//parameter CLOCK_DIVIDE = 1302; // clock rate (50Mhz)  / (baud rate 
(9600)   * 4)
parameter   CLOCK_DIVIDE = 2604; // clock rate (100Mhz) / (baud rate 
(9600)   * 4) by G. Marullo
// parameter   CLOCK_DIVIDE = 217;  // clock rate (100Mhz) / (baud rate 
(115200) * 4) by G. Marullo

// States for the receiving state machine.
// These are just constants, not parameters to override.
parameter RX_IDLE = 0;
parameter RX_CHECK_START = 1;
parameter RX_READ_BITS = 2;
parameter RX_CHECK_STOP = 3;
parameter RX_DELAY_RESTART = 4;
parameter RX_ERROR = 5;
parameter RX_RECEIVED = 6;

// States for the transmitting state machine.
// Constants - do not override.
parameter TX_IDLE = 0;
parameter TX_SENDING = 1;
parameter TX_DELAY_RESTART = 2;

reg [11:0] rx_clk_divider = CLOCK_DIVIDE;
reg [11:0] tx_clk_divider = CLOCK_DIVIDE;

reg [2:0] recv_state = RX_IDLE;
reg [5:0] rx_countdown;
reg [3:0] rx_bits_remaining;
reg [7:0] rx_data;

reg tx_out = 1'b1;
reg [1:0] tx_state = TX_IDLE;
reg [5:0] tx_countdown;
reg [3:0] tx_bits_remaining;
reg [7:0] tx_data;

assign received = recv_state == RX_RECEIVED;
assign recv_error = recv_state == RX_ERROR;
assign is_receiving = recv_state != RX_IDLE;
assign rx_byte = rx_data;

assign tx = tx_out;
assign is_transmitting = tx_state != TX_IDLE;

always @(posedge clk) begin
	if (rst) begin
		recv_state = RX_IDLE;
		tx_state = TX_IDLE;
	end
	
	// The clk_divider counter counts down from
	// the CLOCK_DIVIDE constant. Whenever it
	// reaches 0, 1/16 of the bit period has elapsed.
    // Countdown timers for the receiving and transmitting
	// state machines are decremented.
	rx_clk_divider = rx_clk_divider - 1'b1;
	if (!rx_clk_divider) begin
		rx_clk_divider = CLOCK_DIVIDE;
		rx_countdown = rx_countdown - 1'b1;
	end
	tx_clk_divider = tx_clk_divider - 1'b1;
	if (!tx_clk_divider) begin
		tx_clk_divider = CLOCK_DIVIDE;
		tx_countdown = tx_countdown - 1'b1;
	end
	
	// Receive state machine
	case (recv_state)
		RX_IDLE: begin
			// A low pulse on the receive line indicates the
			// start of data.
			if (!rx) begin
				// Wait half the period - should resume in the
				// middle of this first pulse.
				rx_clk_divider = CLOCK_DIVIDE;
				rx_countdown = 2;
				recv_state = RX_CHECK_START;
			end
		end
		RX_CHECK_START: begin
			if (!rx_countdown) begin
				// Check the pulse is still there
				if (!rx) begin
					// Pulse still there - good
					// Wait the bit period to resume half-way
					// through the first bit.
					rx_countdown = 4;
					rx_bits_remaining = 8;
					recv_state = RX_READ_BITS;
				end else begin
					// Pulse lasted less than half the period -
					// not a valid transmission.
					recv_state = RX_ERROR;
				end
			end
		end
		RX_READ_BITS: begin
			if (!rx_countdown) begin
				// Should be half-way through a bit pulse here.
				// Read this bit in, wait for the next if we
				// have more to get.
				rx_data = {rx, rx_data[7:1]};
				rx_countdown = 4;
				rx_bits_remaining = rx_bits_remaining - 1'b1;
				recv_state = rx_bits_remaining ? RX_READ_BITS[2:0] : RX_CHECK_STOP[2:0];
			end
		end
		RX_CHECK_STOP: begin
			if (!rx_countdown) begin
				// Should resume half-way through the stop bit
				// This should be high - if not, reject the
				// transmission and signal an error.
				recv_state = rx ? RX_RECEIVED[2:0] : RX_ERROR[2:0];
			end
		end
		RX_DELAY_RESTART: begin
			// Waits a set number of cycles before accepting
			// another transmission.
			recv_state = rx_countdown ? RX_DELAY_RESTART[2:0] : RX_IDLE[2:0];
		end
		RX_ERROR: begin
			// There was an error receiving.
			// Raises the recv_error flag for one clock
			// cycle while in this state and then waits
			// 2 bit periods before accepting another
			// transmission.
			rx_countdown = 8;
			recv_state = RX_DELAY_RESTART;
		end
		RX_RECEIVED: begin
			// Successfully received a byte.
			// Raises the received flag for one clock
			// cycle while in this state.
			recv_state = RX_IDLE;
		end
	endcase
	
	// Transmit state machine
	case (tx_state)
		TX_IDLE: begin
			if (transmit) begin
				// If the transmit flag is raised in the idle
				// state, start transmitting the current content
				// of the tx_byte input.
				tx_data = tx_byte;
				// Send the initial, low pulse of 1 bit period
				// to signal the start, followed by the data
				tx_clk_divider = CLOCK_DIVIDE;
				tx_countdown = 4;
				tx_out = 0;
				tx_bits_remaining = 8;
				tx_state = TX_SENDING;
			end
		end
		TX_SENDING: begin
			if (!tx_countdown) begin
				if (tx_bits_remaining) begin
					tx_bits_remaining = tx_bits_remaining - 1'b1;
					tx_out = tx_data[0];
					tx_data = {1'b0, tx_data[7:1]};
					tx_countdown = 4;
					tx_state = TX_SENDING;
				end else begin
					// Set delay to send out 2 stop bits.
					tx_out = 1;
					tx_countdown = 8;
					tx_state = TX_DELAY_RESTART;
				end
			end
		end
		TX_DELAY_RESTART: begin
			// Wait until tx_countdown reaches the end before
			// we send another transmission. This covers the
			// "stop bit" delay.
			tx_state = tx_countdown ? TX_DELAY_RESTART[1:0] : TX_IDLE[1:0];
		end
	endcase
end

endmodule

I had to massage it a bit (a counter was some bits shorter than I 
expected, arrgh), and with some warnings but seems to fit my needs. I 
need up to 4 uarts in a small design, they need to connect the FPGA with 
the pc(diagnostic), USB Host (2) from HobbyTronics for a USB stick and a 
USB keyboard and a serial LCD display (Nice Stuff!).

All can run either 9600 or 115200, and some needs just tx or rx, so I 
could run rtx, rx-only or tx-only versions.

Proably it could be fun to compare the several suggestions you offered 
to decide which is better, but sadly I need to code several other stuff, 
so if this one will work I would not furhter investigate at the moment.

I am testing with the pc, sending simple chars and getting them back 
from the fpga sligtly modified.

Many thanks for the help you give me while I explore this hobby, I would 
be really lost without this group.

Giuseppe Marullo

Article: 153724
Subject: Re: CPU Design in Xilinx Spartan 3E
From: Daniel Kho <daniel.kho@gmail.com>
Date: Mon, 30 Apr 2012 23:08:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
> yes i have done the simulation through a test bench, and getting perfect
> behavioral simulation.
> My code is simple it adds two integer and stores the result in memory.
> In the simulation, I have checked the memory and its right.
> Can i check it on Spartan-3E starter kit through led, lcd or the
> hyperterminal of pc	  =20

Just a suggestion, why not rewrite your testbench to be synthesizable so it=
 become a hardware tester (or BiST)? You can then test your design using a =
logic analyser (I suggest embedded analysers like Altera's SignalTap or Xil=
inx's ChipScope). When the signals appearing on the logic analyser correlat=
e well with your simulation waveforms, you can be pretty sure your design i=
s working.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search