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
In article <ebbn9h019ci@enews1.newsguy.com>, Phil Tomson <ptkwt@aracnet.com> wrote: > >I've got ISE 8.1 running under Linux (Gentoo, 2.6.15 kernel, amd64 - I >plan to use the xc3sprog program to send the bitsream to the board) and >now I'd like to hook up the starter kit board and try it out... >I'd like a simple design that I could run through ISE and download to the >board that would do something on the LEDs so I know things are working, >but I don't see anything like that - according to the README for xc3sprog >there is some design called echo_out that does something like this, but I >can't find it anywhere. Is it (or something similar) available on the web >anywhere? Oops, I misread the README for x3sprog: the echo_out.bit file comes with it. Still, it would be nice to have the source to echo_out (echo_out.vhd?) as well as other designs which manipulate specific items on the starter kit board (like the 7-segment LEDs, for example). PhilArticle: 106201
"Phil Hays" <spampostmaster@comcast.net> schrieb im Newsbeitrag news:pan.2006.08.09.02.22.18.236185@comcast.net... > Antti Lukats wrote: > >> "Austin Lesea" wrote: > >>> The use of a CPLD or FPGA inversion is not recommended for a crystal >>> oscillator. > >> hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 >> caps and crystal will not oscillate under some conditions? > > >> It should be 100% a-stable as it can not stay in non-oscillating state. > > > Back in the 1970's, an engineer I was working for decided to save a part > on a design and use a spare 7414 inverter rather than a 7404 inverter as > an oscillator. > > A TTL inverter, like the 7404, properly connected, makes a good > oscillator. A 7414, which is a schmitt-trigger inverter, doesn't. > > Yes, it would always oscillate. But only sometimes at the correct > frequency. More often at the third or fifth harmonic of the crystal. And > sometimes higher harmonics. > > This left me with the idea that a good engineer should make sure that an > oscillator design is a good design before building boards. Not afterward. > > > -- > Phil Hays > gosh the 7404 and 7414 are totally different chips (in the context of making oscillators). it wasnt much of an engineer who tried crystal osc with 7414. 7414 is good for making RC oscillator with 1 R and 1C (7404 is not) http://focus.ti.com/lit/ds/symlink/sn74lvc1404.pdf and CPLD osc about the same as from above should work. sure it has to tested to work properly on the correct freq and not harmonics AnttiArticle: 106202
Phil Tomson wrote: > I've got ISE 8.1 running under Linux (Gentoo, 2.6.15 kernel, amd64 - I > plan to use the xc3sprog program to send the bitsream to the board) and > now I'd like to hook up the starter kit board and try it out... try this: http://www.xilinx.com/products/boards/DO-SPAR3-DK/reference_designs.htm -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106203
Peter C. Wallace ha scritto: > On Mon, 07 Aug 2006 16:26:36 -0700, fpgakid@gmail.com wrote: > > > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux > > > > Following cables are supported: > > > > Parallel III > > Digilent USB (on Linux it needs libusb, Win32 needs the original driver > > from digilent, utilizes full USB transfer speed!) > > > > Could it support the FTDI-2232? If you need support for FTDI-2232 i wrote a porting for Jamplayer. I think you can use it with Xilinx devices. You can find it here http://teoscorner.byethost6.com/?page_id=6 MatteoArticle: 106204
HI, I hope someone is still reading this thread. I am quite sure now that the matter really are the wrong calibrated clk_count_rise/clk_count_fall signals. Ok, i tried to hardcode them but there are 8 possibliities for both the rising and falling edge. Too many to be tried out. How should I hardcode these two signals?? I tried myself be observing them via chipscope. My hope was that they were set to a different value in the case where everything works fine than in the case where the read out value is wrong. however chipscope ALWAYS showed that the signals are set to rd_en_rise <=3D rd_en_r4; rd_en_fall <=3D rd_en_r3; Firstly, this does not match with my theorie, second I dont trust chipscope, third when I tried the above hardcoded values, I got errrors @EVERY read, so these are not the right values. thx again for any help heiner heinerlitz@gmx.de schrieb: > As I wrote above: > > I observed clk_count_rise and clk_count_fall using chipscope and found > out that they never change which means they are defacto hardcoded. The > delay is hence always the same even without hardcoding the value. > However faillures are still there. > > heiner > > > Joseph Samson schrieb: > > > GaLaKtIkUs=99 wrote: > > > > > Did you hard coded the number of needed clock cycles or the delay in > > > the IDELAY?? > > > Thanks for help! > > > > The number of clock cycles needed, not the IODelay. > >=20 > >=20 > > --- > > Joe Samson > > Pixel VelocityArticle: 106205
On Tue, 08 Aug 2006 23:44:43 GMT, "John_H" <newsgroup@johnhandwork.com> wrote: >I didn't see the verify work and I haven't gone back to see if it could. >The several times I've reprogrammed, the direct JTAG works fine; I've only >programmed the flash load once or twice since direct seems to work. I do >recall some DCM lock problems that *shouldn't* have been there as far as I >could tell (and DCM reset didn't help) but I was actively changing the >design and a next load usually took care of it. Rapid development masks >bugs? > >- John_H > >"David Carne" <david-removeme-carne@shaw.ca> wrote in message >news:20060808162224915-0700@news.vc.shawcable.net... >> I'm experiencing something strange with my Spartan 3 starter kit. It >> seems that when I download a bitstream via jtag directly, things don't >> always work the way they should. However, when I generate a mcs/prm file, >> then burn that prom file to the onboard prom via jtag + boot the fpga >> via that, it works perfectly! I've seen this behavior on multiple >> different designs... no common attribute as to when it happens + when it >> doesnt. I've tried forcing it to verify, but I've never once had that >> succeed, so I don't know if the verify functionality even works. >> >> Has anyone seen this before, and if so, any ideas about a solution? >> >> >> Cheers, >> >> --David Carne I've also seen this happen - not downloading correctly, a second download then works OK. Happenned sufficiently infrequently to not bother investigating further. Note that verify will always fail when downloading via JTAG - this only works when programming the flash.Article: 106206
Hi there, I am doing my first FPGA/VHDL design. Previously I did CPLD designs utilizing Altera's AHDL. I coded the VHDL source files and simulated it successfully with Modelsim. Then I made the I/O pin assignments and made the .bit file and loaded it to the FPGA. To my disappointment only some of the signals are correct; the functionality of the system does not work. I am using ispLEVER and a Lattice LFEC33 FPGA. There is a "Post Place and Route Simulation" action available within ispLEVER (actually it starts Modelsim), but this does not work. Modelsim always complains "Error loading design". What possibilities do I have to debug my design? Thanks a lot, JohannesArticle: 106207
I agree to many of the suggestions, but they are all from a user/implementor view. I would like to add: - André DeHon for real innovative thinking about architectures of FPGAs what an FPGA realy is when compared to a processor - Jason Cong et al. for the Flow Map Algorithm - Tom Kean & Co. from Algotronix for the CAL architecture (later XC6200) - Ross Freeman for the integrated CMOS FPGA - The people (don't know the names) that build FPGAs from seas of discrete muxes with wire wrap interconnect in the 60s and therefor really are the inventors of FPGAs. Kolja SulimmaArticle: 106208
"Antti Lukats" <antti@openchip.org> wrote in message news:ebbtvs$dpr$1@online.de... > "Phil Hays" <spampostmaster@comcast.net> schrieb im Newsbeitrag > and CPLD osc about the same as from above should work. > sure it has to tested to work properly on the correct freq and not > harmonics > I'm sure you meant this, but I'll post it anyway. I'd rather say it has to be _designed_ to work properly. Trial and error is, as I've found through trial and error, a terribly inefficient way to do projects. Cheers, Syms.Article: 106209
Hi Everybody,
I am just starting with the Xilinx Multimedia Board (Virtex II).
I have written a trivial verilog program using ISE 6.3:
-------------------------------------
module mult(c_upper, c_lower);
output [31:0] c_upper;
output [31:0] c_lower;
reg [31:0] ia;
reg [31:0] ib;
reg [63:0] c;
initial begin
ia=32'h10000001;
ib=32'h00000002;
c=ia*ib;
end
assign c_lower=c[31:0];
assign c_upper=c[63:32];
endmodule
---------------------------------------
As for assigning pins, I have used BANK0
for storing the c_upper and c_lower.
The program compiled fine, and the bitstream was generated
and downloaded successfully. But the problem is now, how
do I see the memory where the result is supposed to be present?
It is possible that I am asking a stupid question, but at our
place, nobody has any experience with this board, and I am
having to figure this out on my own.
I would be grateful if you could point me to any suitable document
that might answer my question, or provide a solution.
Thaks in advance.
-Santanu Chatterjee
Article: 106210Hi, For some reason my first post ended up in a complete different thread (XPower: Post-Place and Route Simulation model). Thanks to all of you answered there. Being (in my age still) impatient I sent this post a second time - I apologize for that. Johannes Johannes Hausensteiner wrote: > Hi there, > > I am doing my first FPGA/VHDL design. Previously I did CPLD designs > utilizing Altera's AHDL. > I coded the VHDL source files and simulated it successfully with > Modelsim. Then I made the I/O pin assignments and made the .bit > file and loaded it to the FPGA. To my disappointment only some of > the signals are correct; the functionality of the system does not > work. > I am using ispLEVER and a Lattice LFEC33 FPGA. > There is a "Post Place and Route Simulation" action available within > ispLEVER (actually it starts Modelsim), but this does not work. > Modelsim always complains "Error loading design". > What possibilities do I have to debug my design? > > Thanks a lot, > > JohannesArticle: 106211
Antti Lukats wrote: > gosh the 7404 and 7414 are totally different chips (in the context of making > oscillators). > it wasnt much of an engineer who tried crystal osc with 7414. > 7414 is good for making RC oscillator with 1 R and 1C (7404 is not) > > http://focus.ti.com/lit/ds/symlink/sn74lvc1404.pdf and also the very similar http://www.standardics.philips.com/products/aup/pdf/74aup1z04.pdf > and CPLD osc about the same as from above should work. problem is, cpld osc is not 'about the same', as these devices use unbuffered inverters for the Xtal osc, and Schmitt post buffers. - no presently available CPLD's offer unbuffered inverters, they have loop gains even higher than buffered cmos gates which tyically chain 3 inverters. > sure it has to tested to work properly on the correct freq and not harmonics still leaves edge effects, which are not ideal on a clock source :) -jgArticle: 106212
Hi, I'm confused over two days for the sollution of the next problem: environment: software : WP8.1.03i & WP8.2.01i (tried with both) HW: XC3S400PQG208 I have a board which requires some clock forwarding. Input and output locations are constrained, input clock located at P76 and output located at P165. The problem is with the forwarding. I've tried with DCM, or a simple out<=input; row in the source, but the clock haven't found on output pin (inspected with oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by several reasons. And the reason why I think this to software bug: forwarding works at yesterday for several synthesizing & config stram generation cycle after 30 hours hard error finding. I don't know, how... But I've confused, when I added a simple counter to testing the sychronous network inside the FPGA. Counter wouldn't want to work. I've catched some warnings on the .ncd or .ngd file from the PAR process (maybe corrupt?), I haven't remember, sorry:-/ This occoured to cleanup project files, and after, the forwarding isn't works :((( best regardsArticle: 106213
Jozsef,
after 30 hours of debuging this wire maybe you should rest. After taking
a nap, please check map report for trimmed signals, or post some
files/reports/error messages to see how we can help you.
Aurash
Jozsef wrote:
>Hi,
>
> I'm confused over two days for the sollution of the next problem:
>
>environment:
>software : WP8.1.03i & WP8.2.01i (tried with both)
>HW: XC3S400PQG208
>
>I have a board which requires some clock forwarding. Input and output
>locations are constrained, input clock located at P76 and output
>located at
>P165. The problem is with the forwarding. I've tried with DCM, or a
>simple
>
> out<=input;
>
>row in the source, but the clock haven't found on output pin (inspected
>with
>oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by
>several reasons.
>
>And the reason why I think this to software bug: forwarding works at
>yesterday for several synthesizing & config stram generation cycle
>after 30
>hours hard error finding. I don't know, how... But I've confused, when
>I
>added a simple counter to testing the sychronous network inside the
>FPGA.
>Counter wouldn't want to work. I've catched some warnings on the .ncd
>or
>.ngd file from the PAR process (maybe corrupt?), I haven't remember,
>sorry:-/ This occoured to cleanup project files, and after, the
>forwarding isn't works :(((
>
>best regards
>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 106214
Hello,
I have a little problem, it is about real values in VHDL, and the way =
Quartus is managing them.
I am describing a simple DSP function (filter) in VHDL to implement on a =
Stratix device. As you probabely know, these functions need to shift =
input values in a register bank (declared as "signal" in VHDL), applying =
coefficients (reals) to them. These signals must therefor be of real =
type.
Quartus returns this error on compilation : <snip> Error (10414): VHDL =
error at iir_butterworth_3.vhd(49), at object "X": a real cannot be =
non-constant </snip> ("X" is such a register) Of course the filter =
coefficients (reals) are hardcoded as constants in a package, but these =
shift registers containing reals *are not* constants, they of course =
have to be signals to enable shifting.=20
I have read about obscure floating point units implemented on Stratix =
devices, so I suppose it should be possible to manage real signals =
(floating/fixed point representation ?) in it.=20
Does anyone have an idea about how I can use non-constant reals to =
create a DSP core on Stratix ? I think it is only a synthesis tool =
issue.
Here is the code (no comment on the casts, I *AM* aware this is not the =
most elegant)
A, B, C and D are the filter coefficients.
This description simulates PERFECTLY with Modelsim...
architecture testing of iir_butterworth_3 is
type register_bank is array (0 to 2) of real;
signal X : register_bank;
signal Y : register_bank;
begin
DSP : process(clock, reset, data_in)
begin
if reset =3D '1' then -- initialise registers to 0
for i in 0 to 2 loop
X(i) <=3D 0.0;
Y(i) <=3D 0.0;
end loop; =09
elsif clock'event AND clock =3D '1' then
X(0) <=3D real(conv_integer(data_in));
X(1 to 2) <=3D X(0 to 1); shift X's
=09
Y(0) <=3D ( real(conv_integer(data_in)) + 3.0*X(0) + 3.0*X(1) + =
X(2) - B*Y(0) - C*Y(1) - D*Y(2)) / A;
Y(1 to 2) <=3D Y(0 to 1); shift Y's
end if;
end process DSP;
data_out <=3D conv_std_logic_vector(integer(Y(0)), data_width);
end architecture;
Thanks in advance for the help
Regards,
----------------------------------------------
- Erik Verhagen (div: AB-BI) -
- CERN, Geneva -
- European Organisation for Nuclear Research -
----------------------------------------------
Article: 106215
or better, just add a BUFG in between and make sure you'll use a
dedicated clock pin for this input.
Aurash
Aurelian Lazarut wrote:
> Jozsef,
> after 30 hours of debuging this wire maybe you should rest. After
> taking a nap, please check map report for trimmed signals, or post
> some files/reports/error messages to see how we can help you.
> Aurash
>
> Jozsef wrote:
>
>> Hi,
>>
>> I'm confused over two days for the sollution of the next problem:
>>
>> environment:
>> software : WP8.1.03i & WP8.2.01i (tried with both)
>> HW: XC3S400PQG208
>>
>> I have a board which requires some clock forwarding. Input and output
>> locations are constrained, input clock located at P76 and output
>> located at
>> P165. The problem is with the forwarding. I've tried with DCM, or a
>> simple
>>
>> out<=input;
>>
>> row in the source, but the clock haven't found on output pin (inspected
>> with
>> oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by
>> several reasons.
>>
>> And the reason why I think this to software bug: forwarding works at
>> yesterday for several synthesizing & config stram generation cycle
>> after 30
>> hours hard error finding. I don't know, how... But I've confused, when
>> I
>> added a simple counter to testing the sychronous network inside the
>> FPGA.
>> Counter wouldn't want to work. I've catched some warnings on the .ncd
>> or
>> .ngd file from the PAR process (maybe corrupt?), I haven't remember,
>> sorry:-/ This occoured to cleanup project files, and after, the
>> forwarding isn't works :(((
>>
>> best regards
>>
>>
>>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 106216Hi everybody, I have designed a Cardbus Card with Spartan 3 and Xilinx PCI Core, which works very well in all kind of notebooks, but when I try to use the card within a PC (with a PCI CardBus adapter card - TI PCI-1520 chipset) nothing happens not even the new hardware window comes up. But the PCI CardBus adapter seems to be OK, because if I use a bought 3COM Ethernet Card the new hardware window appears and the driver will be installed. The PCI Cardbus adapter card has exactly the same chipset as one of my test notebook, where the card is working very well. I have also tried to set the boot clock (CCLK) to maximum speed - but the result did not change. I do not really see the difference between a chipset mounted directly on the motherboard and the adapter card. I hope somebody has an idea to solve this problem. With kind regards Nico PresserArticle: 106217
Are you sure you're getting your required voltage(s) from the cardbus adapter? If your requested voltages are not available you normally don't get powered up at all. I've found that 3.3v is the only voltage you can reliably expect on a cardbus adapter. HTH, Gabor Weltraumbaer wrote: > Hi everybody, > > I have designed a Cardbus Card with Spartan 3 and Xilinx PCI Core, > which works very well in all kind of notebooks, but when I try to use > the card within a PC (with a PCI CardBus adapter card - TI PCI-1520 > chipset) nothing happens not even the new hardware window comes up. But > the PCI CardBus adapter seems to be OK, because if I use a bought 3COM > Ethernet Card the new hardware window appears and the driver will be > installed. The PCI Cardbus adapter card has exactly the same chipset as > one of my test notebook, where the card is working very well. I have > also tried to set the boot clock (CCLK) to maximum speed - but the > result did not change. I do not really see the difference between a > chipset mounted directly on the motherboard and the adapter card. > > I hope somebody has an idea to solve this problem. > > With kind regards > Nico PresserArticle: 106218
Hi all, Thank you for your fast response. Meanwhile I have tried another notebook with a different CardBus chipset (TI PCI-1520) and I did not believe what I have seen. Everything was working as it should be. With master read command 1 DW was transferred, with master read line command 8 DW's were transferred and with master read multiple command 4kB in a row were transferred with the maximum of 1 retry after initial request!!! Nico PresserArticle: 106219
Hi Gabor, As far as I know CardBus does only support 3,3V. In older PCMCIA systems you could choose between 5V and 3,3V. Nevertheless my card is based on 3,3V. NicoArticle: 106220
Kolja Sulimma schrieb: > John_H wrote: > > Weltraumbaer wrote: > >> Hello, > >> > >> I have designed a CardBus Design, which is very similar to pci with > >> full master functionality. The main aim of this card is to transfer a > >> huge amount of data to and from PC RAM to the CardBus card. But in > >> master read mode I very often get a target retry. The fact of an target > >> retry (in this case the pc is the target) is not abnormal but I have > >> scanned the pci bus and I have seen a lot of target retries in series > >> -> sometimes more then 100 in a row. This is absolute unacceptable due > >> to the poor bus performance -> so my fifo's run out of data. The common > >> pc memory (ram) is locked from driver and is set as non cacheable. > >> > >> I hope that somebody can help me in this issue. I am not really sure if > >> this is a hardware or a software (driver) problem. > > We learned the hard way that PCI is just not intended to read at high data rates. > Some chipset will even split a single 128-bit read (SSE2 move) of the CPU into > two PCI accesses. You can't really expect the chipset to be nicer to your expansion > board than it is to the CPU. > > I would not really on getting any read bursts larger than a cache line to work without > tuning chipset specific registers. > > Kolja Sulimma Hi Kolja, do you know if SSE2 moves would be normally translated to 64 bit PCI(X) transfers or not? I am working with PCI-X ipcore where backend is always 64bits so sometimes I would like the PC host software todo atomic 64 bit read writes but I found no way. It should be doable only with 64 bit OS as the Intel 64 bit extensions are not accessible in 32 bit OSes (so I have understood it at least). I have been reading intel specs, but as far as I understand on 32 bit OS there is no almost no way to force a programatic 64 bit access from the CPU - maybe I missed something. I only looked at CPU commands not the SSE2 -- as of burst - sometimes it works like magic, as example I see an PCI 64 bit master to transfer 4KB blocks to PC main memory as almost continous stream, eg 512 clocks for 4kbyte, then after a few clocks next block, etc.. not a single retry! sure master reads would yield more retries AnttiArticle: 106221
Hi Bart, Thanks for the link. bart wrote: > Johannes Hausensteiner wrote: > >> What possibilities do I have to debug my design? > > Hi Johannes, > besides comp.arch.fpga and other usenet groups, you could post your > questions on Lattice's support forum: > > http://www.latticesemi.com/support/forums.cfm > > hope this helps. > regards, > bart borosky, lattice >Article: 106222
Hi André, Thanks for your answer; yes I added my testbench to the ispLEVER project and assosiated it to the FPGA chip. I get three entries in right pane of the ispLEVER ProjectNavigator: - VHDL Functional Simulation - VHDL Post-Route Functional Simulation - VHDL Post-Route Timing Simulation When I double-click on any of them Modelsim is started and it compiles and tries to load the design. In all three of them there are following error messages in Modelsim: -- snip --- # ** Error: (vsim-3170) Could not find 'work.StimModule_Unknown'. # Error loading design # Error: Error loading design # Pausing macro execution -- snip --- The name "work.StimModule_Unknown" is used for each and every design I tried up to now. When I replace this in the (by ispLEVER generated) do-files (test_bench.fdo, test_bench.xdo, test_bench.tdo) with the name of the testbench then the "Functional Simulation" will work. The "Post-Route Functional Simulation" and the "Post-Route Timing Simulation" will still refuse to load in Modelsim with the following error: -- snip --- # Loading work.tb_counter(test_counter) # ** Error: (vsim-13) Recompile work.counter(everything) because work.counter has changed. # Error loading design # Error: Error loading design -- snip --- This does not change when I actually recompile "counter", "work.counter", or the whole design. While once more double-checking I found out the following: for the "Post-Route ... Simulation" ispLEVER decompiles what it has routed to a VHDL file named "design.vho". This uses the architecture name "Structure". For the testbench to be loaded correctly within Modelsim is has (of course) to be of architecture "Structure", too (which was in the case in my design). - OK, this one is clear; I can live with the "work.StimModule_Unknown" thing. So thank you for your replies! Johannes ALuPin@web.de wrote: > Hi Johannes, > > did you import the testbench file and associate it to the device in > ispLEVER? > By doing that you can start functional and timing simulation when > marking > the device. > > Besides are you using VHDL packages ? > > Rgds > André > > >> There is a "Post Place and Route Simulation" action available within >> ispLEVER (actually it starts Modelsim), but this does not work. >> Modelsim always complains "Error loading design". >> What possibilities do I have to debug my design? >> >> Thanks a lot, >> >> Johannes >Article: 106223
Aurash,
Now changes the situation, but I stand with incomprehension. Now, the
clock are forwarded, but and significantly but, synchronous upcounter
isn't work.
The design & report files attached below.
-------------- c.vhd ---------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;
entity c is
Port ( clk : in STD_LOGIC;
sys_clk_out: out std_logic;
q : out STD_LOGIC
);
end c;
architecture Behavioral of c is
signal aaaa : std_logic_vector(6 downto 0);
signal i_clk: std_logic;
port (I: in STD_LOGIC;
O: out STD_LOGIC);
end component;
begin
internalclock: bufg port map(clk,i_clk);
process(i_clk) ----this counter is not work, why????
begin
if rising_edge(i_clk) then
aaaa<=aaaa+"0000001";
end if;
end process;
Sys_Clk_out<=clk;
q<=aaaa(6);
end Behavioral;
--------------end of c.vhd ---------
-------------- c.ucf ----------
#PACE: Start of Constraints generated by PACE
#PACE: Start of PACE I/O Pin Assignments
NET "clk" LOC = "P76" | IOSTANDARD = LVCMOS33 ; # gclk2
NET "q" LOC = "P95" | IOSTANDARD = LVCMOS33 | SLEW = FAST | DRIVE =
12 ; #IO
NET "sys_clk_out" LOC = "P165" | IOSTANDARD = LVCMOS33 | SLEW = FAST
; # IO
#PACE: Start of PACE Area Constraints
#PACE: Start of PACE Prohibit Constraints
#PACE: End of Constraints generated by PACE
------------end of c.ucf--------------------
-----------------SYNTHESIZE REPORT---------------------
Release 8.2.01i - xst I.32
Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved.
--> Parameter TMPDIR set to ./xst/projnav.tmp
CPU : 0.00 / 1.51 s | Elapsed : 0.00 / 1.00 s
--> Parameter xsthdpdir set to ./xst
CPU : 0.00 / 1.51 s | Elapsed : 0.00 / 1.00 s
--> Reading design: c.prj
TABLE OF CONTENTS
1) Synthesis Options Summary
2) HDL Compilation
3) Design Hierarchy Analysis
4) HDL Analysis
5) HDL Synthesis
5.1) HDL Synthesis Report
6) Advanced HDL Synthesis
6.1) Advanced HDL Synthesis Report
7) Low Level Synthesis
8) Partition Report
9) Final Report
9.1) Device utilization summary
9.2) TIMING REPORT
=========================================================================
* Synthesis Options Summary
*
=========================================================================
---- Source Parameters
Input File Name : "c.prj"
Input Format : mixed
Ignore Synthesis Constraint File : NO
---- Target Parameters
Output File Name : "c"
Output Format : NGC
Target Device : xc3s400-4-pq208
---- Source Options
Top Module Name : c
Automatic FSM Extraction : YES
FSM Encoding Algorithm : Auto
FSM Style : lut
RAM Extraction : Yes
RAM Style : Auto
ROM Extraction : Yes
Mux Style : Auto
Decoder Extraction : YES
Priority Encoder Extraction : YES
Shift Register Extraction : YES
Logical Shifter Extraction : YES
XOR Collapsing : YES
ROM Style : Auto
Mux Extraction : YES
Resource Sharing : YES
Multiplier Style : auto
Automatic Register Balancing : No
---- Target Options
Add IO Buffers : YES
Global Maximum Fanout : 500
Add Generic Clock Buffer(BUFG) : 8
Register Duplication : YES
Slice Packing : YES
Pack IO Registers into IOBs : auto
Equivalent register Removal : YES
---- General Options
Optimization Goal : Speed
Optimization Effort : 1
Keep Hierarchy : NO
RTL Output : Yes
Global Optimization : AllClockNets
Write Timing Constraints : NO
Hierarchy Separator : /
Bus Delimiter : <>
Case Specifier : maintain
Slice Utilization Ratio : 100
Slice Utilization Ratio Delta : 5
---- Other Options
lso : c.lso
Read Cores : YES
cross_clock_analysis : NO
verilog2001 : YES
safe_implementation : No
Optimize Instantiated Primitives : NO
use_clock_enable : Yes
use_sync_set : Yes
use_sync_reset : Yes
=========================================================================
=========================================================================
* HDL Compilation
*
=========================================================================
Compiling vhdl file "C:/XilinxProjects/Dummy1/c.vhd" in Library work.
Entity <c> compiled.
Entity <c> (Architecture <behavioral>) compiled.
=========================================================================
* Design Hierarchy Analysis
*
=========================================================================
Analyzing hierarchy for entity <c> in library <work> (architecture
<behavioral>).
Building hierarchy successfully finished.
=========================================================================
* HDL Analysis
*
=========================================================================
Analyzing Entity <c> in library <work> (Architecture <behavioral>).
WARNING:Xst:2211 - "C:/XilinxProjects/Dummy1/c.vhd" line 58:
Instantiating black box module <BUFG>.
Entity <c> analyzed. Unit <c> generated.
=========================================================================
* HDL Synthesis
*
=========================================================================
Performing bidirectional port resolution...
Synthesizing Unit <c>.
Related source file is "C:/XilinxProjects/Dummy1/c.vhd".
Found 7-bit up counter for signal <aaaa>.
Summary:
inferred 1 Counter(s).
Unit <c> synthesized.
=========================================================================
HDL Synthesis Report
Macro Statistics
# Counters : 1
7-bit up counter : 1
=========================================================================
=========================================================================
* Advanced HDL Synthesis
*
=========================================================================
Loading device for application Rf_Device from file '3s400.nph' in
environment C:\Xilinx.
=========================================================================
Advanced HDL Synthesis Report
Macro Statistics
# Counters : 1
7-bit up counter : 1
=========================================================================
=========================================================================
* Low Level Synthesis
*
=========================================================================
Optimizing unit <c> ...
Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block c, actual ratio is 0.
Final Macro Processing ...
=========================================================================
Final Register Report
Macro Statistics
# Registers : 7
Flip-Flops : 7
=========================================================================
=========================================================================
* Partition Report
*
=========================================================================
Partition Implementation Status
-------------------------------
No Partitions were found in this design.
-------------------------------
=========================================================================
* Final Report
*
=========================================================================
Final Results
RTL Top Level Output File Name : c.ngr
Top Level Output File Name : c
Output Format : NGC
Optimization Goal : Speed
Keep Hierarchy : NO
Design Statistics
# IOs : 3
Cell Usage :
# BELS : 8
# LUT2 : 2
# LUT3 : 2
# LUT4 : 2
# LUT4_D : 1
# VCC : 1
# FlipFlops/Latches : 7
# FD : 6
# FDR : 1
# Clock Buffers : 1
# BUFG : 1
# IO Buffers : 3
# IBUFG : 1
# OBUF : 2
=========================================================================
Device utilization summary:
---------------------------
Selected Device : 3s400pq208-4
Number of Slices: 4 out of 3584 0%
Number of Slice Flip Flops: 7 out of 7168 0%
Number of 4 input LUTs: 7 out of 7168 0%
Number of IOs: 3
Number of bonded IOBs: 3 out of 141 2%
Number of GCLKs: 1 out of 8 12%
=========================================================================
TIMING REPORT
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.
Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal | Clock buffer(FF name) | Load |
-----------------------------------+------------------------+-------+
clk | IBUFG+BUFG | 7 |
-----------------------------------+------------------------+-------+
Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design
Timing Summary:
---------------
Speed Grade: -4
Minimum period: 4.186ns (Maximum Frequency: 238.892MHz)
Minimum input arrival time before clock: No path found
Maximum output required time after clock: 7.241ns
Maximum combinational path delay: 7.743ns
Timing Detail:
--------------
All values displayed in nanoseconds (ns)
=========================================================================
Timing constraint: Default period analysis for Clock 'clk'
Clock period: 4.186ns (frequency: 238.892MHz)
Total number of paths / destination ports: 28 / 7
-------------------------------------------------------------------------
Delay: 4.186ns (Levels of Logic = 2)
Source: aaaa_3 (FF)
Destination: aaaa_5 (FF)
Source Clock: clk rising
Destination Clock: clk rising
Data Path: aaaa_3 to aaaa_5
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
FD:C->Q 2 0.720 1.216 aaaa_3 (aaaa_3)
LUT4_D:I0->O 2 0.551 0.945 Mcount_aaaa_cy<3>11
(Mcount_aaaa_cy<3>)
LUT3:I2->O 1 0.551 0.000 Mcount_aaaa_xor<5>11
(Result<5>)
FD:D 0.203 aaaa_5
----------------------------------------
Total 4.186ns (2.025ns logic, 2.161ns route)
(48.4% logic, 51.6% route)
=========================================================================
Timing constraint: Default OFFSET OUT AFTER for Clock 'clk'
Total number of paths / destination ports: 1 / 1
-------------------------------------------------------------------------
Offset: 7.241ns (Levels of Logic = 1)
Source: aaaa_6 (FF)
Destination: q (PAD)
Source Clock: clk rising
Data Path: aaaa_6 to q
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
FD:C->Q 2 0.720 0.877 aaaa_6 (aaaa_6)
OBUF:I->O 5.644 q_OBUF (q)
----------------------------------------
Total 7.241ns (6.364ns logic, 0.877ns route)
(87.9% logic, 12.1% route)
=========================================================================
Timing constraint: Default path analysis
Total number of paths / destination ports: 1 / 1
-------------------------------------------------------------------------
Delay: 7.743ns (Levels of Logic = 2)
Source: clk (PAD)
Destination: sys_clk_out (PAD)
Data Path: clk to sys_clk_out
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
IBUFG:I->O 2 1.222 0.877 clk_IBUFG
(sys_clk_out_OBUF)
OBUF:I->O 5.644 sys_clk_out_OBUF
(sys_clk_out)
----------------------------------------
Total 7.743ns (6.866ns logic, 0.877ns route)
(88.7% logic, 11.3% route)
=========================================================================
CPU : 12.40 / 13.98 s | Elapsed : 13.00 / 14.00 s
-->
Total memory usage is 137084 kilobytes
Number of errors : 0 ( 0 filtered)
Number of warnings : 1 ( 0 filtered)
Number of infos : 0 ( 0 filtered)
-------------------END OF SYNTHESIZE REPORT------------------------
-------------------TRANSLATE REPORT---------------------------------
Release 8.2.01i ngdbuild I.32
Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved.
Command Line: C:\Xilinx\bin\nt\ngdbuild.exe -ise
C:/XilinxProjects/Dummy1/Dummy1.ise -intstyle ise -dd _ngo -nt
timestamp -uc
c.ucf -p xc3s400-pq208-4 c.ngc c.ngd
Reading NGO file 'C:/XilinxProjects/Dummy1/c.ngc' ...
Applying constraints in "c.ucf" to the design...
Checking timing specifications ...
Checking Partitions ...
Checking expanded design ...
Partition Implementation Status
-------------------------------
No Partitions were found in this design.
-------------------------------
NGDBUILD Design Results Summary:
Number of errors: 0
Number of warnings: 0
Total memory usage is 65956 kilobytes
Writing NGD file "c.ngd" ...
Writing NGDBUILD log file "c.bld"...
--------------------END OF TRANSLATION REPORT-----------------
-------------------MAP REPORT----------------------------------------
elease 8.2.01i Map I.32
Xilinx Mapping Report File for Design 'c'
Design Information
------------------
Command Line : C:\Xilinx\bin\nt\map.exe -ise
C:/XilinxProjects/Dummy1/Dummy1.ise -intstyle ise -p xc3s400-pq208-4
-cm
balanced -detail -ignore_keep_hierarchy -pr b -k 4 -c 100 -bp -o
c_map.ncd c.ngd
c.pcf
Target Device : xc3s400
Target Package : pq208
Target Speed : -4
Mapper Version : spartan3 -- $Revision: 1.34.32.1 $
Mapped Date : Wed Aug 09 16:00:49 2006
Design Summary
--------------
Number of errors: 0
Number of warnings: 1
Logic Utilization:
Number of Slice Flip Flops: 7 out of 7,168 1%
Number of 4 input LUTs: 7 out of 7,168 1%
Logic Distribution:
Number of occupied Slices: 5 out of
3,584 1%
Number of Slices containing only related logic: 5 out of
5 100%
Number of Slices containing unrelated logic: 0 out of
5 0%
*See NOTES below for an explanation of the effects of unrelated
logic
Total Number of 4 input LUTs: 7 out of 7,168 1%
Number of bonded IOBs: 3 out of 141 2%
Number of GCLKs: 1 out of 8 12%
Total equivalent gate count for design: 101
Additional JTAG gate count for IOBs: 144
Peak Memory Usage: 138 MB
NOTES:
Related logic is defined as being logic that shares connectivity -
e.g. two
LUTs are "related" if they share common inputs. When assembling
slices,
Map gives priority to combine logic that is related. Doing so
results in
the best timing performance.
Unrelated logic shares no connectivity. Map will only begin packing
unrelated logic into a slice once 99% of the slices are occupied
through
related logic packing.
Note that once logic distribution reaches the 99% level through
related
logic packing, this does not mean the device is completely utilized.
Unrelated logic packing will then begin, continuing until all usable
LUTs
and FFs are occupied. Depending on your timing budget, increased
levels of
unrelated logic packing may adversely affect the overall timing
performance
of your design.
Table of Contents
-----------------
Section 1 - Errors
Section 2 - Warnings
Section 3 - Informational
Section 4 - Removed Logic Summary
Section 5 - Removed Logic
Section 6 - IOB Properties
Section 7 - RPMs
Section 8 - Guide Report
Section 9 - Area Group and Partition Summary
Section 10 - Modular Design Summary
Section 11 - Timing Report
Section 12 - Configuration String Information
Section 1 - Errors
------------------
Section 2 - Warnings
--------------------
WARNING:LIT:243 - Logical network N9 has no load.
Section 3 - Informational
-------------------------
INFO:MapLib:562 - No environment variables are currently set.
INFO:MapLib:535 - The following Virtex BUFG(s) is/are being retargetted
to
Virtex2 BUFGMUX(s) with input tied to I0 and Select pin tied to
constant 0:
BUFG symbol "internalclock" (output signal=i_clk)
INFO:MapLib:331 - Block RAM optimization summary:
INFO:MapLib:333 - No optimization performed
Section 4 - Removed Logic Summary
---------------------------------
1 block(s) removed
1 block(s) optimized away
1 signal(s) removed
1 Block(s) redundant
Section 5 - Removed Logic
-------------------------
The trimmed logic report below shows the logic removed from your design
due to
sourceless or loadless signals, and VCC or ground connections. If the
removal
of a signal or symbol results in the subsequent removal of an
additional signal
or symbol, the message explaining that second removal will be indented.
This
indentation will be repeated as a chain of related logic is removed.
To quickly locate the original cause for the removal of a chain of
logic, look
above the place where that logic is listed in the trimming report, then
locate
the lines that are least indented (begin at the leftmost edge).
The signal "N9" is loadless and has been removed.
Loadless block "XST_GND" (ZERO) removed.
Optimized Block(s):
TYPE BLOCK
VCC XST_VCC
Redundant Block(s):
TYPE BLOCK
LOCALBUF Mcount_aaaa_cy<3>11/LUT4_D_BUF
Section 6 - IOB Properties
--------------------------
+------------------------------------------------------------------------------------------------------------------------+
| IOB Name | Type | Direction | IO
Standard | Drive | Slew | Reg (s) | Resistor | IOB |
| | | |
| Strength | Rate | | | Delay |
+------------------------------------------------------------------------------------------------------------------------+
| clk | IOB | INPUT | LVCMOS33
| | | | | |
| q | IOB | OUTPUT | LVCMOS33
| 12 | FAST | | | |
| sys_clk_out | IOB | OUTPUT | LVCMOS33
| 12 | FAST | | | |
+------------------------------------------------------------------------------------------------------------------------+
Section 7 - RPMs
----------------
Section 8 - Guide Report
------------------------
Guide not run on this design.
Section 9 - Area Group and Partition Summary
--------------------------------------------
Partition Implementation Status
-------------------------------
No Partitions were found in this design.
-------------------------------
Area Group Information
----------------------
No area groups were found in this design.
----------------------
Section 10 - Modular Design Summary
-----------------------------------
Modular Design not used for this design.
Section 11 - Timing Report
--------------------------
This design was not run using timing mode.
Section 12 - Configuration String Details
-----------------------------------------
BUFGMUX "internalclock": Configuration String is:
"DISABLE_ATTR:LOW I0_USED:0 SINV:S_B"
-----------------END OF MAP REPORT ------------------------------
------------------PAR REPORT--------------------------------------
Release 8.2.01i par I.32
Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved.
JOZSEF:: Wed Aug 09 16:00:57 2006
par -w -intstyle ise -ol std -t 1 c_map.ncd c.ncd c.pcf
Constraints file: c.pcf.
Loading device for application Rf_Device from file '3s400.nph' in
environment C:\Xilinx.
"c" is an NCD, version 3.1, device xc3s400, package pq208, speed -4
Initializing temperature to 85.000 Celsius. (default - Range: 0.000 to
85.000 Celsius)
Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260
Volts)
INFO:Par:282 - No user timing constraints were detected or you have set
the option to ignore timing constraints ("par
-x"). Place and Route will run in "Performance Evaluation Mode" to
automatically improve the performance of all
internal clocks in this design. The PAR timing summary will list the
performance achieved for each clock. Note: For
the fastest runtime, set the effort level to "std". For best
performance, set the effort level to "high". For a
balance between the fastest runtime and best performance, set the
effort level to "med".
Device speed data version: "PRODUCTION 1.39 2006-06-02".
Device Utilization Summary:
Number of BUFGMUXs 1 out of 8 12%
Number of External IOBs 3 out of 141 2%
Number of LOCed IOBs 3 out of 3 100%
Number of Slices 5 out of 3584 1%
Number of SLICEMs 0 out of 1792 0%
Overall effort level (-ol): Standard
Placer effort level (-pl): High
Placer cost table entry (-t): 1
Router effort level (-rl): Standard
Starting Placer
Phase 1.1
Phase 1.1 (Checksum:98969a) REAL time: 4 secs
Phase 2.7
Phase 2.7 (Checksum:1312cfe) REAL time: 5 secs
Phase 3.31
Phase 3.31 (Checksum:1c9c37d) REAL time: 5 secs
Phase 4.2
.
Phase 4.2 (Checksum:26259fc) REAL time: 8 secs
Phase 5.8
.
.
.
.
.
Phase 5.8 (Checksum:98c4fb) REAL time: 8 secs
Phase 6.5
Phase 6.5 (Checksum:39386fa) REAL time: 8 secs
Phase 7.18
Phase 7.18 (Checksum:42c1d79) REAL time: 8 secs
Phase 8.5
Phase 8.5 (Checksum:4c4b3f8) REAL time: 8 secs
Writing design to file c.ncd
Total REAL time to Placer completion: 8 secs
Total CPU time to Placer completion: 6 secs
Starting Router
Phase 1: 33 unrouted; REAL time: 8 secs
Phase 2: 27 unrouted; REAL time: 8 secs
Phase 3: 6 unrouted; REAL time: 9 secs
Phase 4: 6 unrouted; (197) REAL time: 9 secs
Phase 5: 10 unrouted; (0) REAL time: 9 secs
Phase 6: 0 unrouted; (0) REAL time: 9 secs
Phase 7: 0 unrouted; (0) REAL time: 9 secs
Total REAL time to Router completion: 9 secs
Total CPU time to Router completion: 6 secs
Partition Implementation Status
-------------------------------
No Partitions were found in this design.
-------------------------------
Generating "PAR" statistics.
**************************
Generating Clock Report
**************************
+---------------------+--------------+------+------+------------+-------------+
| Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max
Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
| i_clk | BUFGMUX2| No | 5 | 0.000 |
1.034 |
+---------------------+--------------+------+------+------------+-------------+
* Net Skew is the difference between the minimum and maximum routing
only delays for the net. Note this is different from Clock Skew which
is reported in TRCE timing report. Clock Skew is the difference between
the minimum and maximum path delays which includes logic delays.
The Delay Summary Report
The NUMBER OF SIGNALS NOT COMPLETELY ROUTED for this design is: 0
The AVERAGE CONNECTION DELAY for this design is: 0.772
The MAXIMUM PIN DELAY IS: 4.295
The AVERAGE CONNECTION DELAY on the 10 WORST NETS is: 1.116
Listing Pin Delays by value: (nsec)
d < 1.00 < d < 2.00 < d < 3.00 < d < 4.00 < d < 5.00 d >=
5.00
--------- --------- --------- --------- ---------
---------
24 6 0 0 1
0
Timing Score: 0
Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.
------------------------------------------------------------------------------------------------------
Constraint | Requested | Actual |
Logic | Absolute |Number of
| | |
Levels | Slack |errors
------------------------------------------------------------------------------------------------------
Autotimespec constraint for clock net i_c | N/A | 2.842ns |
2 | N/A | N/A
lk | | |
| |
------------------------------------------------------------------------------------------------------
All constraints were met.
INFO:Timing:2761 - N/A entries in the Constraints list may indicate
that the
constraint does not cover any paths or that it has no requested
value.
Generating Pad Report.
All signals are completely routed.
Total REAL time to PAR completion: 10 secs
Total CPU time to PAR completion: 7 secs
Peak Memory Usage: 126 MB
Placement: Completed - No errors found.
Routing: Completed - No errors found.
Number of error messages: 0
Number of warning messages: 0
Number of info messages: 1
Writing design to file c.ncd
PAR done!
---------------------END OF PAR REPORT---------------------------
Aurelian Lazarut wrote:
> or better, just add a BUFG in between and make sure you'll use a
> dedicated clock pin for this input.
> Aurash
>
> Aurelian Lazarut wrote:
>
> > Jozsef,
> > after 30 hours of debuging this wire maybe you should rest. After
> > taking a nap, please check map report for trimmed signals, or post
> > some files/reports/error messages to see how we can help you.
> > Aurash
> >
> > Jozsef wrote:
> >
> >> Hi,
> >>
> >> I'm confused over two days for the sollution of the next problem:
> >>
> >> environment:
> >> software : WP8.1.03i & WP8.2.01i (tried with both)
> >> HW: XC3S400PQG208
> >>
> >> I have a board which requires some clock forwarding. Input and output
> >> locations are constrained, input clock located at P76 and output
> >> located at
> >> P165. The problem is with the forwarding. I've tried with DCM, or a
> >> simple
> >>
> >> out<=input;
> >>
> >> row in the source, but the clock haven't found on output pin (inspected
> >> with
> >> oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by
> >> several reasons.
> >>
> >> And the reason why I think this to software bug: forwarding works at
> >> yesterday for several synthesizing & config stram generation cycle
> >> after 30
> >> hours hard error finding. I don't know, how... But I've confused, when
> >> I
> >> added a simple counter to testing the sychronous network inside the
> >> FPGA.
> >> Counter wouldn't want to work. I've catched some warnings on the .ncd
> >> or
> >> .ngd file from the PAR process (maybe corrupt?), I haven't remember,
> >> sorry:-/ This occoured to cleanup project files, and after, the
> >> forwarding isn't works :(((
> >>
> >> best regards
> >>
> >>
> >>
> >
> >
>
>
> --
> __
> / /\/\ Aurelian Lazarut
> \ \ / System Verification Engineer
> / / \ Xilinx Ireland
> \_\/\/
>
> phone: 353 01 4032639
> fax: 353 01 4640324
Article: 106224
oops,
c.vhd incorrect in my last post.
the correct c.vhd is:
---------- c.vhd ------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;
entity c is
Port ( clk : in STD_LOGIC;
sys_clk_out: out std_logic;
q : out STD_LOGIC
);
end c;
architecture Behavioral of c is
signal aaaa : std_logic_vector(6 downto 0);
signal i_clk: std_logic;
component BUFG
port (I: in STD_LOGIC;
O: out STD_LOGIC);
end component;
begin
internalclock: bufg port map(clk,i_clk);
process(i_clk)
begin
if rising_edge(i_clk) then
aaaa<=aaaa+"0000001";
end if;
end process;
Sys_Clk_out<=clk;
q<=aaaa(6);
end Behavioral;
----------end of c.vhd---------------
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