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
Moti wrote: > > Hi Jhon, > thanks for your reply, altough I have to admit that I didnt entirely > understood how to actually caluculate the frequency. > Best regards, Moti I think he is saying that you should expect the maximum deviations to be n/m * Fref and n+1/m * Fref where n/m is the closest integer ratio that gives you an exact frequency that the NCO can make without jitter. Example: Fref is 1 MHz, Fout is 211 kHz, 32 bit accumulator. This gives a step size of Fout/Fref * 2^32 = 906,238,099.456 ~= 906,238,099. This will roll over the MSB on 4 or 5 clock pulses. So your Fout will be composed of pulses of 4 clocks and pulses of 5 clocks with high and low times of 2 and 3 clocks. The corresponding jitter will be... geeze, this is hard isn't it? I think you will get Fref/6 and Fref/2 as the range of jitter. I think the formula should be... Fmax = floor(Fref/(2*Fout)) * 0.5 Fmin = ceiling(Fref/(2*Fout)) * 0.5 Fjitter = Fmax-Fmin I expect you will see main peaks in your FFT at Fmax and Fmin, no? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76576
In the past there were the XC3000/3100 and XC4000 FPGA parts available in the PCC84 IC package. They were rather small capacity parts, however probably are still available. -- Regards, Pavel "Vadim Vaynerman" <vadimv@ieee.org> wrote in message news:ee8a751.0@webx.sUN8CHnE... > Sorry about that, I missclicked... > > My question is this: is there ANY Xilinx FPGA that comes in a PLCC84 or > PC84 package that is supported by the WebPck tools? I couldn't find that > package for Spartan II devices, only for CPLDs, and I really want to use > an FPGA. Any Ideas? > > Thanks > > VadimArticle: 76577
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:41B4AF23.5CCD7DA7@yahoo.com... > Example: Fref is 1 MHz, Fout is 211 kHz, 32 bit accumulator. This gives > a step size of Fout/Fref * 2^32 = 906,238,099.456 ~= 906,238,099. This > will roll over the MSB on 4 or 5 clock pulses. So your Fout will be > composed of pulses of 4 clocks and pulses of 5 clocks with high and low > times of 2 and 3 clocks. The corresponding jitter will be... geeze, > this is hard isn't it? If someone really want to break this down to the last bit, I got a PHD paper here that is all about DDS, spectrum etc. But its german, 3 Mb pdf. If someone is intereted, drop me a mail. Regards FalkArticle: 76578
Antti Lukats wrote:
>
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:41B49989.E7D9EFBC@yahoo.com...
> > Antti Lukats wrote:
> > >
> > > [lots of snipped]
> > > > > Rick, hmmm... care to comment?
> > > > > see synthesis and timing reports above :)
> > > >
> [snip]
> > > I used all signal 32 bit wide, inc_value as input port
> >
> > That should work. Can you post the code you worked with?
> > --
> > Rick "rickman" Collins
>
> Rick you can try your own code with XST it complains about the sll at least!
> Maybe there is better(read proper fix) to main
>
> the timings I posted I always posted synthesis estimae and post P&R timings
> news posting did change the text aligne so was hard to read
>
> below is what I used (fast-do-not-think-at-all .. fixed) from your code
> ----------------------------------------------------------------------------
> ---
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> entity dds is
> Port ( clk : in std_logic;
> rst : in std_logic;
> inc_value : in std_logic_vector(31 downto 0);
> fout : out std_logic);
> end dds;
>
> architecture Behavioral of dds is
>
> signal accsingle : std_logic_vector(31 downto 0);
> signal accdouble : std_logic_vector(31 downto 0);
> signal accfast : std_logic_vector(31 downto 0);
> signal phase : std_logic;
>
> begin
>
> process (clk, rst)
> begin
> if rst = '1' then
> phase <= '0';
> accsingle <= (others =>'0');
> accdouble <= (others =>'0');
> accfast <= (others =>'0');
> elsif clk'event and clk ='1' then
> phase <= not phase;
> if (phase = '0') then
> accfast <= accsingle;
> else
> accfast <= accdouble;
> accsingle <= accdouble + inc_value;
> accdouble <= accdouble + (inc_value(30 downto 0) & '0');
> end if;
> end if;
> end process;
>
> fout <= accfast (accfast'high);
>
> end Behavioral;
This looks good to me. I found the sll in a book that warned about not
always being supported in synthesis since it was VHDL-1993 and still new
at that time. Jeeze, you would think XST would have gotten up the curve
by now.
But this code looks good to me. It should produce the following
hardware..
accsingle ====X=======X=======X=
accdouble ====X=======X=======X=
accfast X===X===X===X===X===X=
_ _ _ _ _ _
+--0<|---+ Clock | |_| |_| |_| |_| |_|
| | ___ ___ ___
| +---+ | Phase | |___| |___| |__
+-| |--+--------+------------------------+
| | | |
|> | | |
+---+ | V Left shift one bit |
+---------)-------------+ |
| | | |
| |\ | | |\ |
| | \ | | | \ |
-------+-| \ | +--| \ |
| \ | accsingle | \ | accdouble
inc_value \ | | +----+ \ | | +----+
> |--)--| |--+ > |--)--| |--+
/ | | | | | / | | | | |
| / +--|En | | | / +--|En | |
+--| / | | | +--| / | | | |
| | / |> | | | | / | |> | |
| |/ +----+ | | |/ | +----+ |
| | | | |
+---------------------)--+----------)----------+
| | |
| | |\--------+
| +---| \ accfast
| | | +----+
| | |--------| |---->
| | | | |
+-------------------------| / | |
|/ | |
|> |
+----+
The paths leading to accsingle and accdouble have two clock cycles to
settle and the paths to accfast has to settle in one clock cycle.
Looking at this, I realize that the accfast does not need the full 32
bits since only the MSb is used. So the LUT count should be 32 * 2 + 2
= 66.
The timing constraints must reflect the proper delays (2 clocks default
with one clock on all paths ending at accfast and all paths starting at
phase. Then the critical path will be one of the one clock paths which
should be able to be optimized to much faster than 200 MHz. Without the
timing constraints, the tools will analyze the adder paths as the
critical paths and report wrong timings.
The Spartan 3 CLB has input setup and clock to output delays of about
0.7 ns. With a routing delay of 1 ns between FFs in the same CLB, (I am
estimating a worst case routing delay, *really* worst case) this gives
2.4 ns or over 400 MHz. I guess the routing of the phase signal to the
32 bit registers may be a bit slower, but good floorplanning should
speed this up. Heck, I can get close to this speed in a relatively slow
and *ancient* ACEX part from Altera. I am sure the Spartan 3 can do
better.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 76579Hello Marc The is that for the DDR2 SDRAM controller, the time constraints are such that the higher speed grade is required, which increases the FPGA cost by about $100. We would clock the DDR2 with a clock frequency at the lower bound (say 133 MHz), so that theoretically it should work with the lower speed grade. But we are not quite sure if this would really work. A distributor of Micron memory suggested to use DDR2 because normal DDR would solwly disappear during 2005. For RocketIO board-to-board communication we plan to use serial ATA cables and connectors, with bandwidth up to 2Gbits/s, with a cable length around 50cm, using XC2VP30. Did you already use RocketIO? Which speed? Did you encounter any problems? Regards Viktor "Marc Randolph" <mrand@my-deja.com> wrote in message news:w5udnSU8EtsLRyzcRVn-vQ@comcast.com... > Viktor Steinlin wrote: >> Hello, >> I'm about to design a frame grabber where I need high memory bandwidth. >> Does anybody has already implemented a design with Xilinx Virtex-II PRO >> and DDR2 SDRAM. Have you encountered major problems with DDR2 controller >> provided by Xilinx EDK? Some design hints? >> >> What about Rocket IO. Did you encounter problems on connecting two FPGAs >> over short (50cm) cable? Or does it work on first try, if the layout is >> done properly? > > Howdy Viktor, > > I can't help you with the DDR2 SDRAM controller, but for as long as it > has been out, I'd be surprised if there were any serious problems with > using it. > > As for the Rocket I/O over cable, what kind of cable are you going to use? > Over what distance? At what speed? With which Xilinx part? > > Good luck, > > Marc --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.802 / Virus Database: 545 - Release Date: 11/26/2004Article: 76580
Jason Berringer wrote: > > Hello all, > > I'm curious to hear some comments on the following idea. I had a bus > interface (total of 9, 16 bit wide registers) that I had originally designed > a large bus multiplexer for. The select lines were coded into a 9 bit vector > "000000001" when the first register was addressed, "000000010" when the > second register was addressed, and so on, all controlled via address lines, > chip selects, and read strobes. This seemed to produce a fair amount of > logic, and slower speeds so I thought of using the 9 bit select vector to > control internal tristates i.e. : > > data <= register1 when sel(0) = '1' else (others 'Z'). > data <= register2 when sel(1) = '1' else (others 'Z'). > data <= register3 when sel(2) = '1' else (others 'Z'). > > Since I haven't seen this done before in my searches I was curious to see > some comments on it. Pros, cons, is it an acceptable means to accomplish > this or should I stick to the bus multiplexer. All comments are appreciated. This is similar to what I do for wide muxes. But I don't bother with the tristate. I use decoded signals like you have above, sel(n). They are both easier to create and use (in terms of logic). I then AND each bus with its enable and OR together the result. If you want to "help" the software optimally map this to LUTs, you can use two data inputs to a LUT along with the two enables. Then four of these LUTs can be combined in one LUT to give an 8 input mux in five LUTs. The most Xilinx parts will give you an 8 input mux using 4 LUTs and some give a 16 input mux using 8 LUTs since they include the muxes to combine LUTs. Otherwise my approach above is the best I have found that is (relatively) technology independant. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76581
Ahhh, that explains the issues with the ANT then... ;-) MarkArticle: 76582
The NEW and improved Google groups seems to work nicely: http://groups-beta.google.com MarkArticle: 76583
Hi, I was wondering if anyone in this group can provide some insight as to how hard it might be to get an FPGA to act as a USB host, for collecting data at quite a high-bandwidth. Particularly can this reasonably be done at all with a completely hardware implementation, possibly with an external embedded USB host controller. Or would I be much better off using some kind of soft-core CPU to collect and format data from the USB peripheral due complexity of driving an embedded USB host controller? Thanks, - JakeArticle: 76584
In article <41B4BC59.BBC5F852@yahoo.com>, rickman <john@bluepal.net> wrote:
>I use decoded signals like you have above, sel(n). They are both easier
>to create and use (in terms of logic). I then AND each bus with its
>enable and OR together the result. If you want to "help" the software
>optimally map this to LUTs, you can use two data inputs to a LUT along
>with the two enables. Then four of these LUTs can be combined in one
>LUT to give an 8 input mux in five LUTs.
This works better than the tristate logic which some parts (Xilinx) have.
You can use the verilog wired-or type to avoid a lot of typing:
// register file
wor [15:0] read_bus; // 16 N-input OR gates.
bus_register #(.ADDRESS(0)) control
(
.read_data (read_bus), ...
);
bus_register #(.ADDRESS(1)) status
(
.read_data (read_bus), ...
);
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 76585"Rudolf Usselmann" <russelmann@hotmail.com> wrote in message news:cp1p3d$cuq$1@nobel.pacific.net.sg... > Sean Durkin wrote: >> Rudolf Usselmann wrote: >>> >>> Just upgraded ISE and EDK to 6.3 from 6.2. We use a small SoC >>> consisting of a microblaze, SDRAM/DDRAM controllers and RS232 >>> (uartlite). >>> >>> We use various development boards from Memec-Insight with >>> Virtex 1000 and VP20. We always use microblaze CPU, and >>> depending on the development board SDRAM or DDRAM controllers. >>> >>> Anyway, after the upgrade, the soc seems to be broken. Looks >>> like the UART output is somewhat garbled. I don't want to >>> debug the SoC again, just because I upgraded the tools. >> Garbled UART output sounds like the baudrate may be incorrect. Maybe the >> UART-settings somehow got lost/changed during the upgrade? Or maybe they >> changed the name of the parameter that sets the baudrate in the latest >> version of the UART-core. >> Is the UART the only problem and everything else is working fine? >> >> cu, >> Sean > > Sorry, I was not very clear. The UART prints half of the message > ok, than skips a lot than again a few readable words ... > > I did check all the obvious things like baud rate etc. Thats not > it. There seems some fundamental difference. The SoC seems to > "hang" as well. Like may be something in the software changed ... > it still does compile clean, and I did re-compile everything ... > I spend two days trying to figure out what was wrong, than switched > back to EDK 6.2. > > Thanks, > rudi > ============================================================= > Rudolf Usselmann, ASICS World Services, http://www.asics.ws > Your Partner for IP Cores, Design, Verification and Synthesis Rudolf, If you had the old EDK6.2i elf file and the EDK6.3i elf file, perhaps you could do a mb-objdump on both and then do a diff. The differences may provide a clue to where the problem may be, or maybe not. I read something about EDK6.3 transitioning to an Eclipse based look and feel software environment, and that there is a graphical linker tool now. Maybe your software suspicions are justified. -Regards NewmanArticle: 76586
Paolo, Great to hear about your success! I will be getting my cable tomorrow and hope to start using the board as soon as I am able to program the Spartan. Regarding the speed setting, when set at 5MHz transfer rate, the cable will try to use ECP mode of the parallel port. Check your PC's BIOS setting to see if it is set to ECP. Most systems are set at SPP or EPP by default. This is just a guess and I can not say for sure that this will be the only problem, especially since I haven't laid my hands on the cable yet. regards, Sirish "Mindroad" <mindroad@hotmail.com> wrote in message news:41b35bb7$0$9311$ba620e4c@news.skynet.be... > Sirish, > > I sucessfully programmed the Spartan with Parallel IV cable with the bridge, > i'm sorry to have bothered you with this question, since within 4h i found a > manual describing what u said, still thanks a lot for replying. > > I encountered some problems downloading the pci bridge design though, at > first the data transfer rate over the cable was set at 5 MHz, stopping the > download process and crashing my PC, when I had put it on 2.5 MHz it still > didn't worked, eventually i have put it on 200 KHz and this worked just > fine. > iMPACT allows u to set the rate. > > Good luck to you, and thanks for the help ! > Greetings, > > Paolo > > "Sirish" <sirishka_no_spam@hotmail.com> schreef in bericht > news:coi6h4$1ep$1@nntp.msstate.edu... > > Paolo, > > > > As far as I understand, the board comes with the Spartan loaded with the > > "pass-thru" bit file. This allows the board to be tested/used without > > plugging it into a PCI slot. So, till you are able to load the bridge > > program > > onto the spartan, the board will not be seen by the PC. > > I have placed an order for a JTAG4 cable, but haven't received it yet. > Plan > > to > > try it again after i am able to program the spartan. > > > > -Sirish > >Article: 76587
Hi Rick
SLL will work for numeric_std.unsigned or bit vector:
http://groups-beta.google.com/groups?q=vhdl+sll+sla+treseler
Thanks for the code example.
Nice demo of area vs. speed at the hdl level.
-- Mike Treseler
Article: 76588Hi Rickman, Lots of thanks for the explanation and the numeric example. I will defently use it and afterwards I will probably measure the actual jitter frequency and compare it to the calculated results - when I'll get the results I will post them (for those intersted).. Thanks again, Moti.Article: 76589
Hi Falk, My german is pretty "rusty" :) so if the document is in .pdf format it will very hard... but if it's in a html format it can translated by google and then it will be possible to read it! Regards, Moti.Article: 76590
Actel has more space experience than any other FPGA. If you want non-volatile,
and the features fit your application, then Actel is the way to go. Rich Katz
is a
good resource. Also, you'd do well to review the proceedings from the MAPLD
conferences. That conference is heavy on space application of FPGAs.
For John Jackson: there are lots of FPGAs in space now. Actel has been used in
space applications for over a decade. Xilinx FPGAs are also being used in
space applications, including the Mars Rover. I've done a few designs slated
for
low earth orbit. Xilinx has a line of radiation tolerant devices that have
additional
process steps to guard against SEU induced latch-up. Depending on the
application,
there are various degrees of fault tolerance/correction that can be applied. It
all
depends on how big a problem it is if the particular circuit is upset. There
are
many advantages to using FPGAs in space apps, especially reconfigurable ones
like the Xilinx parts.
Thomas Stanka wrote:
> mitrusc1980-newsgroup@yahoo.com.br (Marcio A. A. Fialho) wrote
> > Does anyone knows if Actel still manufactures obsolete and
> > legacy rad-hard (or rad-tolerant) parts like RT1460A or
> > RT54SX16 ? I think these parts would suit or needs.
> > I will ask Actel about this.
>
> At least there should be devices deliverabel. Never tried to get one
> of them, but RH1020 are still in stock (RT1020 are out of order).
>
> > Thomas Stanka (usenet_10@stanka-web.de) wrote:
> > > ...
> > > What to you mean with "user gates"? 2input-NAND? 4 input LUT
> > > When an RH1020 is to small you need an RT54SX32S. But be aware,
> > > there's currently a relability problem when using the RT54SX-S
> > > devices.
> > >
> > What reliability problem is this related to the RT54SX-S devices?
>
> There's a problem due to the possibility of having weak fuses which
> might increase the delay of a path in your design. This antifuse might
> be stable for up to 2100h before showing this delay.
> Try starting with klabs.org to get more details, as this problem is
> very new, there are a lot of "uncertain" informations.
>
> > Does this reliability problem affects RTSX-SU devices?
>
> No, only the availability of UMC-Parts *g*.
>
> > Actel told me that RT54SX-X and RTSX-SU are based in the
> > same design. The difference is that RT54SX-X parts are
> > manufactured by MEC and RT54SX-SU are produced at UMC.
>
> Yes thats right. The basic difference is that UMC-Parts use an other
> fuse design. A second point is, that the inrush-current issue due to
> power cycling is solved in UMC-parts.
>
> > > > P.S: ASICs (Field Gate Arrays) would be OK, provided it cost less than
> > > > US$10,000.00 and takes less than a month or two to be fabricated. In
> > > > case we opt for an ASIC, only around 3-5 units would be produced.
> > >
> > > I know no alternative when spending 30-50k$ for that number. AFAIK
> > > there are Actel fpgas above 10k$ per device.
> >
> > It seems that an ASIC is indeed very expensive. Anyone has a value for the
> > cheapest rad-tolerant ASICs (around 1k 2input NAND-gates) ?
>
> Well the price depends on many factors like quantity, flow and so on.
> The cheapest device suitable for long term missions should be the
> RH1020 with ~2000 NAND2-gates. The RT54SX32S device in B-Flow should
> be quite cheaper, in E-Flow a bit more expensive than the RH1020.
>
> bye Thomas
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 76591It's involved... With your example of 211kHz from a 1MHz reference, the ratio of 906,238,099/2^32 has closest fractions in order of worst to best of 1/5 4/19 23/109 211/1000 1987386/9418891 19873649/94187910 57633561/273144839 The offsets are the ideal frequency compared to the ratio frequency: 211 kHz - 200 kHz 211 kHz - 210.52632 kHz 211 kHz - 211.00917 kHz 211 kHz - 211 kHz... Here Excel starts to lose digits: The difference between 906,238,099/2^32 and 906,238,099.456/2^32 is about 5.03e-10 at which point small amounts of jitter are lost. If the jitter at that tiny offset is large, you will experience phase jumps when that beat frequency is felt. There's no way to filter those with analog filters. Your largest observed peaks in the spectrum will be at offsets of 11 kHz, 526 Hz, and 9.17 Hz. You should be able to see the 526 Hz modulating the 11kHz for spikes much smaller than the 11 kHz peak. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:41B4AF23.5CCD7DA7@yahoo.com... > Moti wrote: > > > > Hi Jhon, > > thanks for your reply, altough I have to admit that I didnt entirely > > understood how to actually caluculate the frequency. > > Best regards, Moti > > I think he is saying that you should expect the maximum deviations to be > n/m * Fref and n+1/m * Fref where n/m is the closest integer ratio that > gives you an exact frequency that the NCO can make without jitter. > > Example: Fref is 1 MHz, Fout is 211 kHz, 32 bit accumulator. This gives > a step size of Fout/Fref * 2^32 = 906,238,099.456 ~= 906,238,099. This > will roll over the MSB on 4 or 5 clock pulses. So your Fout will be > composed of pulses of 4 clocks and pulses of 5 clocks with high and low > times of 2 and 3 clocks. The corresponding jitter will be... geeze, > this is hard isn't it? > > I think you will get Fref/6 and Fref/2 as the range of jitter. I think > the formula should be... > > Fmax = floor(Fref/(2*Fout)) * 0.5 > Fmin = ceiling(Fref/(2*Fout)) * 0.5 > Fjitter = Fmax-Fmin > > I expect you will see main peaks in your FFT at Fmax and Fmin, no? > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76592
Thanks for the tips, and hints. Very useful indeed. Jason "Jason Berringer" <jberringer.at@sympatico.dot.ca> wrote in message news:O4Psd.15588$dC3.197817@news20.bellglobal.com... > Hello all, > > I'm curious to hear some comments on the following idea. I had a bus > interface (total of 9, 16 bit wide registers) that I had originally designed > a large bus multiplexer for. The select lines were coded into a 9 bit vector > "000000001" when the first register was addressed, "000000010" when the > second register was addressed, and so on, all controlled via address lines, > chip selects, and read strobes. This seemed to produce a fair amount of > logic, and slower speeds so I thought of using the 9 bit select vector to > control internal tristates i.e. : > > data <= register1 when sel(0) = '1' else (others 'Z'). > data <= register2 when sel(1) = '1' else (others 'Z'). > data <= register3 when sel(2) = '1' else (others 'Z'). > > Since I haven't seen this done before in my searches I was curious to see > some comments on it. Pros, cons, is it an acceptable means to accomplish > this or should I stick to the bus multiplexer. All comments are appreciated. > > I'm using a Spartan II just in case anyone is interested. > > Thanks > > Jason > >Article: 76593
Thanx!!!!!
I'm trying to understand something about UART, I've downloaded some IP
cores, some app notes...
But if I'll add to my design a very simple UART, with a little
controller, how can i communicate with that? I downloaded the core
UART from www.opencores.org, can I read/load data from/to it with
Windows Hyperterminal (I have win2000)?
And how?
Here's the miniUART entity
entity miniUART is
port (
SysClk : in Std_Logic; -- System Clock
Reset : in Std_Logic; -- Reset input
CS_N : in Std_Logic;
RD_N : in Std_Logic;
WR_N : in Std_Logic;
RxD : in Std_Logic;
TxD : out Std_Logic;
IntRx_N : out Std_Logic; -- Receive interrupt
IntTx_N : out Std_Logic; -- Transmit interrupt
Addr : in Std_Logic_Vector(1 downto 0); --
DataIn : in Std_Logic_Vector(7 downto 0); --
DataOut : out Std_Logic_Vector(7 downto 0)); --
end entity;
-------------------------------------------------------------------------------
-- Architecture for miniUART Controller Unit
-------------------------------------------------------------------------------
architecture uart of miniUART is
-----------------------------------------------------------------------------
-- Signals
-----------------------------------------------------------------------------
signal RxData : Std_Logic_Vector(7 downto 0); --
signal TxData : Std_Logic_Vector(7 downto 0); --
signal CSReg : Std_Logic_Vector(7 downto 0); -- Ctrl & status
register
-- CSReg detailed
-----------+--------+--------+--------+--------+--------+--------+--------+
-- CSReg(7)|CSReg(6)|CSReg(5)|CSReg(4)|CSReg(3)|CSReg(2)|CSReg(1)|CSReg(0)|
-- Res | Res | Res | Res | UndRun | OvrRun | FErr |
OErr |
-----------+--------+--------+--------+--------+--------+--------+--------+
signal EnabRx : Std_Logic; -- Enable RX unit
signal EnabTx : Std_Logic; -- Enable TX unit
signal DRdy : Std_Logic; -- Receive Data ready
signal TRegE : Std_Logic; -- Transmit register empty
signal TBufE : Std_Logic; -- Transmit buffer empty
signal FErr : Std_Logic; -- Frame error
signal OErr : Std_Logic; -- Output error
signal Read : Std_Logic; -- Read receive buffer
signal Load : Std_Logic; -- Load transmit buffer
-----------------------------------------------------------------------------
-- Baud rate Generator
-----------------------------------------------------------------------------
component ClkUnit is
port (
SysClk : in Std_Logic; -- System Clock
EnableRX : out Std_Logic; -- Control signal
EnableTX : out Std_Logic; -- Control signal
Reset : in Std_Logic); -- Reset input
end component;
-----------------------------------------------------------------------------
-- Receive Unit
-----------------------------------------------------------------------------
component RxUnit is
port (
Clk : in Std_Logic; -- Clock signal
Reset : in Std_Logic; -- Reset input
Enable : in Std_Logic; -- Enable input
RxD : in Std_Logic; -- RS-232 data input
RD : in Std_Logic; -- Read data signal
FErr : out Std_Logic; -- Status signal
OErr : out Std_Logic; -- Status signal
DRdy : out Std_Logic; -- Status signal
DataIn : out Std_Logic_Vector(7 downto 0));
end component;
-----------------------------------------------------------------------------
-- Transmitter Unit
-----------------------------------------------------------------------------
component TxUnit is
port (
Clk : in Std_Logic; -- Clock signal
Reset : in Std_Logic; -- Reset input
Enable : in Std_Logic; -- Enable input
Load : in Std_Logic; -- Load transmit data
TxD : out Std_Logic; -- RS-232 data output
TRegE : out Std_Logic; -- Tx register empty
TBufE : out Std_Logic; -- Tx buffer empty
DataO : in Std_Logic_Vector(7 downto 0));
end component;
begin
-----------------------------------------------------------------------------
-- Instantiation of internal components
-----------------------------------------------------------------------------
ClkDiv : ClkUnit port map (SysClk,EnabRX,EnabTX,Reset);
TxDev : TxUnit port map
(SysClk,Reset,EnabTX,Load,TxD,TRegE,TBufE,TxData);
RxDev : RxUnit port map
(SysClk,Reset,EnabRX,RxD,Read,FErr,OErr,DRdy,RxData);
-----------------------------------------------------------------------------
-- Implements the controller for Rx&Tx units
-----------------------------------------------------------------------------
RSBusCtrl : process(SysClk,Reset,Read,Load)
variable StatM : Std_Logic_Vector(4 downto 0);
begin
if Rising_Edge(SysClk) then
if Reset = '0' then
StatM := "00000";
IntTx_N <= '1';
IntRx_N <= '1';
CSReg <= "11110000";
else
StatM(0) := DRdy;
StatM(1) := FErr;
StatM(2) := OErr;
StatM(3) := TBufE;
StatM(4) := TRegE;
end if;
case StatM is
when "00001" =>
IntRx_N <= '0';
CSReg(2) <= '1';
when "10001" =>
IntRx_N <= '0';
CSReg(2) <= '1';
when "01000" =>
IntTx_N <= '0';
when "11000" =>
IntTx_N <= '0';
CSReg(3) <= '1';
when others => null;
end case;
if Read = '1' then
CSReg(2) <= '0';
IntRx_N <= '1';
end if;
if Load = '1' then
CSReg(3) <= '0';
IntTx_N <= '1';
end if;
end if;
end process;
-----------------------------------------------------------------------------
-- Combinational section
-----------------------------------------------------------------------------
process(SysClk)
begin
if (CS_N = '0' and RD_N = '0') then
Read <= '1';
else Read <= '0';
end if;
if (CS_N = '0' and WR_N = '0') then
Load <= '1';
else Load <= '0';
end if;
if Read = '0' then
DataOut <= "ZZZZZZZZ";
elsif (Read = '1' and Addr = "00") then
DataOut <= RxData;
elsif (Read = '1' and Addr = "01") then
DataOut <= CSReg;
end if;
if Load = '0' then
TxData <= "ZZZZZZZZ";
elsif (Load = '1' and Addr = "00") then
TxData <= DataIn;
end if;
end process;
end uart; --===================== End of architecture
=======================--
Article: 76594>Subject: PAL programming >From: dan.costin@gmail.com >Date: 12/6/04 10:02 AM Pacific Standard Time > >I have a PAL16V8 and I know I can program in verilog or vhdl... But >what I need use for obtaining a programming_file and what circuit I >need to use for programm the chip (I'm new in this domain...I used only >fpga). You need a programmer, almost any of them can do the pal16v8, if you don't have one someone around you should have one. Prob. a lot of people on this site would program a few of them for you from a JEDEC File. RockyArticle: 76595
>I'm trying to understand something about UART, I've downloaded some IP
>cores, some app notes...
>But if I'll add to my design a very simple UART, with a little
>controller, how can i communicate with that? I downloaded the core
>UART from www.opencores.org, can I read/load data from/to it with
>Windows Hyperterminal (I have win2000)?
>And how?
You have to build a FSM that reads characters from the UART
and turns that into operations on your SRAM.
It would probably be easier to write in software but
it shouldn't be too hard a problem to do in real hardware.
I assume it would go something like this:
You have an address register and a data register.
Digiits get shifted into the data register.
Octal or hex, your choice.
Or use A through J to simplify the hardware.
A couple of special characters do reads and writes.
For example:
A / character copies the data from the
data register into the address register
does a read cycle
sends back the data now in the data register
A $ character stores the data register at the
currently addressed location. (which was loaded
by a / above.)
Everything else gets ignored. Or turns on an error LED.
To go faster, you can automatically bump the address after
each write.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Article: 76596John_H wrote: > It's involved... > With your example of 211kHz from a 1MHz reference, the ratio of > 906,238,099/2^32 has closest fractions in order of worst to best of > > 1/5 > 4/19 > 23/109 > 211/1000 > 1987386/9418891 > 19873649/94187910 > 57633561/273144839 > > The offsets are the ideal frequency compared to the ratio frequency: > 211 kHz - 200 kHz > 211 kHz - 210.52632 kHz > 211 kHz - 211.00917 kHz > 211 kHz - 211 kHz... Here Excel starts to lose digits: > > The difference between 906,238,099/2^32 and 906,238,099.456/2^32 is about > 5.03e-10 at which point small amounts of jitter are lost. If the jitter at > that tiny offset is large, you will experience phase jumps when that beat > frequency is felt. There's no way to filter those with analog filters. > > Your largest observed peaks in the spectrum will be at offsets of 11 kHz, > 526 Hz, and 9.17 Hz. You should be able to see the 526 Hz modulating the > 11kHz for spikes much smaller than the 11 kHz peak. Good example maths, but is the principle right ? For the example of 211KHz from 1Mhz, you have 1us quantize, and so will be able to generate 4us, or 5us periods, giving 250KHz and 200KHz. Over many cycles, the 'wobbling' between these two will average to 211KHz. The more cycles, the better the match to 211KHz. Over a 6 cycle snapshot, you might see 5@200, 1@250, and Favge 208.33Khz That's appx one part in 77 too slow. This 6 cycle frame has a freq of 34.6KHz Next frame group would be (eg) every 79 cycles, to see => 14 @ 250KHz, 65@ 200KHz => 210.76923Khz, Error is now one part in 1000, and this finer frame is 2.65KHz ( etc ) as over wider frame snap-shots, the average frequency gets closer to the 211KHz ideal. So I'd expect to see, on a spectrum analyser, 200KHz, (Dominant) 250KHz and 34.6KHz and 2.65KHz (etc) energies. -jgArticle: 76597
I have developed a Xilinx Sparta IIE system using Handel C. In the system, I am using dual port block ram to store data. I would like to know how to integrate a VHDL component which can read data from the dual port rams ? I have read through the handel C reference manual and search through google, but there is no such an example given. Could anyone help me on this as this is really urgent? thank you. If anyone knows how to define the interface, please help me on this, thank youArticle: 76598
On Tue, 07 Dec 2004 15:34:36 +1300, Jim Granville <no.spam@designtools.co.nz> wrote: >John_H wrote: >> It's involved... >> With your example of 211kHz from a 1MHz reference, the ratio of >> 906,238,099/2^32 has closest fractions in order of worst to best of >> >> 1/5 >> 4/19 >> 23/109 >> 211/1000 >> 1987386/9418891 >> 19873649/94187910 >> 57633561/273144839 >> >> The offsets are the ideal frequency compared to the ratio frequency: >> 211 kHz - 200 kHz >> 211 kHz - 210.52632 kHz >> 211 kHz - 211.00917 kHz >> 211 kHz - 211 kHz... Here Excel starts to lose digits: >> >> The difference between 906,238,099/2^32 and 906,238,099.456/2^32 is about >> 5.03e-10 at which point small amounts of jitter are lost. If the jitter at >> that tiny offset is large, you will experience phase jumps when that beat >> frequency is felt. There's no way to filter those with analog filters. >> >> Your largest observed peaks in the spectrum will be at offsets of 11 kHz, >> 526 Hz, and 9.17 Hz. You should be able to see the 526 Hz modulating the >> 11kHz for spikes much smaller than the 11 kHz peak. > >Good example maths, but is the principle right ? > > >For the example of 211KHz from 1Mhz, you have 1us quantize, and so will >be able to generate 4us, or 5us periods, giving 250KHz and 200KHz. > >Over many cycles, the 'wobbling' between these two will average to >211KHz. The more cycles, the better the match to 211KHz. > >Over a 6 cycle snapshot, you might see 5@200, 1@250, and Favge 208.33Khz >That's appx one part in 77 too slow. >This 6 cycle frame has a freq of 34.6KHz > >Next frame group would be (eg) >every 79 cycles, to see => 14 @ 250KHz, 65@ 200KHz => 210.76923Khz, >Error is now one part in 1000, and this finer frame is 2.65KHz >( etc ) as over wider frame snap-shots, the average frequency gets >closer to the 211KHz ideal. > >So I'd expect to see, on a spectrum analyser, 200KHz, (Dominant) 250KHz >and 34.6KHz and 2.65KHz (etc) energies. Did you actually plug it in to a spectrum analyser and see those tones? Ten highest spurious tones: 55.000kHz -11.4dBc 367.000kHz -16.7dBc 101.000kHz -17.0dBc 165.000kHz -22.4dBc 9.000kHz -22.9dBc 257.000kHz -24.1dBc 321.000kHz -25.1dBc 147.000kHz -25.8dBc 119.000kHz -27.4dBc 37.000kHz -27.7dBc Regards, AllanArticle: 76599
Allan Herriman wrote: > On Tue, 07 Dec 2004 15:34:36 +1300, Jim Granville > <no.spam@designtools.co.nz> wrote: > > >>John_H wrote: >> >>>It's involved... >>>With your example of 211kHz from a 1MHz reference, the ratio of >>>906,238,099/2^32 has closest fractions in order of worst to best of >>> >>>1/5 >>>4/19 >>>23/109 >>>211/1000 >>>1987386/9418891 >>>19873649/94187910 >>>57633561/273144839 >>> >>>The offsets are the ideal frequency compared to the ratio frequency: >>>211 kHz - 200 kHz >>>211 kHz - 210.52632 kHz >>>211 kHz - 211.00917 kHz >>>211 kHz - 211 kHz... Here Excel starts to lose digits: >>> >>> The difference between 906,238,099/2^32 and 906,238,099.456/2^32 is about >>>5.03e-10 at which point small amounts of jitter are lost. If the jitter at >>>that tiny offset is large, you will experience phase jumps when that beat >>>frequency is felt. There's no way to filter those with analog filters. >>> >>>Your largest observed peaks in the spectrum will be at offsets of 11 kHz, >>>526 Hz, and 9.17 Hz. You should be able to see the 526 Hz modulating the >>>11kHz for spikes much smaller than the 11 kHz peak. >> >>Good example maths, but is the principle right ? >> >> >>For the example of 211KHz from 1Mhz, you have 1us quantize, and so will >>be able to generate 4us, or 5us periods, giving 250KHz and 200KHz. >> >>Over many cycles, the 'wobbling' between these two will average to >>211KHz. The more cycles, the better the match to 211KHz. >> >>Over a 6 cycle snapshot, you might see 5@200, 1@250, and Favge 208.33Khz >>That's appx one part in 77 too slow. >>This 6 cycle frame has a freq of 34.6KHz >> >>Next frame group would be (eg) >>every 79 cycles, to see => 14 @ 250KHz, 65@ 200KHz => 210.76923Khz, >>Error is now one part in 1000, and this finer frame is 2.65KHz >>( etc ) as over wider frame snap-shots, the average frequency gets >>closer to the 211KHz ideal. >> >>So I'd expect to see, on a spectrum analyser, 200KHz, (Dominant) 250KHz >>and 34.6KHz and 2.65KHz (etc) energies. > > > Did you actually plug it in to a spectrum analyser and see those > tones? No, it was just 'back of an envelope' stuff, to get a feel for what repetition frames are likely, and so what the likely energies are. > > Ten highest spurious tones: > > 55.000kHz -11.4dBc > 367.000kHz -16.7dBc > 101.000kHz -17.0dBc > 165.000kHz -22.4dBc > 9.000kHz -22.9dBc > 257.000kHz -24.1dBc > 321.000kHz -25.1dBc > 147.000kHz -25.8dBc > 119.000kHz -27.4dBc > 37.000kHz -27.7dBc Are these rounded to the nearest KHz, as I can't derive 55.00KHz either... a 19 cycle @ 1MHz frame, would be 52.63KHz ? It also seems strange to not see 200KHz, 250KHz... ? -jg
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