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
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, JurgenArticle: 153701
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.comArticle: 153702
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.itArticle: 153703
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, JurgenArticle: 153704
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, JurgenArticle: 153705
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, > > JurgenArticle: 153706
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: 153707Hello 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
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.itArticle: 153709
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 PArticle: 153710
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= osArticle: 153711
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 WebberArticle: 153712
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 MarulloArticle: 153713
"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! AndyArticle: 153714
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/frankbussArticle: 153715
> 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 MarulloArticle: 153716
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
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: 153718Giuseppe 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
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/frankbussArticle: 153720
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.comArticle: 153721
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
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
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> 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:
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