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
Paul Boven wrote: > Having studied the datasheet quite well before getting into this, it is > a lot easier for me to map a desired circuit into FFs, LUTs and the > like. Learning VHDL or even using the schematic editor, feels like a > terribly involved way to convince the software to configure those LUTs > the way I want them. So yes, I can imagine some demand for a FPGA layout > tool that stays this close to the hardware. But 'realy slick and > commercial' probably would put it out of my reach. HDL's not too bad for laying things out like this, if you have regular structures, because you can express the relationships algorithmically, and then easily mix and match this structural code with higher level, less speed critical HDL code. My 2c, JeremyArticle: 85476
"Dimitri Turbiner" <dima_turbiner@yahoo-dot-com.no-spam.invalid> wrote in message news:UeqdnS6cqvrGQTXfRVn_vg@giganews.com... > Hi Alex, I couldn't find your original email so I thought posting on > CAStalk > Here's my original message: > >> >> Hi Alex, >> >> I'm Dimitri Turbiner. >> Actually I'm extremely interested in working exactly >> on the XUPv2p board and since I saw your post on >> CAStalk that you have already a working instalation of >> Linux I would like to ask you some questions: No I'm not the one with the working version of linux yet. A few people on the uclinux microblaze mailing list have. I suggest posting on the mailing list and asking them your questions. John Williams has uclinux working on it. http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux original messages were on the uclinux microblaze mailing list http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/ see below for messages I'm still waiting on the board to be purchased (takes a while through the university) Alex From the original messages dated 29.04.2005 Or http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html I've already used these helpful references to get a Linux kernel running on the PowerPC405 on the Digilent XUP-V2Pro board. I'm new to ucLinux but it doesn't appear to be much more complicated than the ucLinux steps. Paul Hi Aurash, hi John, > > We are working with the PPC on virtex2p. You do not need Monta Vista > Linux. > All you need is denx eldk: http://www.denx.de/twiki/bin/view/DULG/ELDK > And the penguin ppc linux distribution: > http://www.penguinppc.org/kernel/#developers > (we are using the 2.4 Kernel) > To get started: http://www.klingauf.de/v2p/index.phtml might be helpful. > > On the other hand we are also using uClinux on spartan3. > It is really a question of what hardware you have and what you want to do > ;-) > > Have Fun > JanArticle: 85477
If you want to save some coin, you should look at the Lattice EC fpgas. They have built in DQS & clock domain transfer logic to support DDR memory up to 200Mhz. Although density is not as large as V4, you can get up to a 33k or 40k LUT device. Symon wrote: > "Antti Lukats" <antti@openchip.org> wrote in message > news:d88m0o$be1$03$1@news.t-online.com... > > > > Q: as the DDR chips are mounted VERY close, all wires less than 0.5 inch? > > and there is never more than one load on the DDR chips, I am wondering is > it > > safe to not have DDR termination resistors by using DCI in the FPGA and > > switching the DDR into SSTL1 mode by the extended mode register write? > > > Antti, > If the risetime is six times the flight time of the traces, you'll probably > be safe without terminations. Risetime 1ns => 1 inch trace length in FR4. > (25.4mm for metric Estonians! Actually, are Estonians metric?) Trace length > must, of course, include the bond wires, bga traces, lead frames. > Cheers, Syms.Article: 85478
> Without knowing what PCB technology you're using, it's impossible to say. > Here are a few questions off the top of my head. > Can you use microvias? What's your minimum track width? Minimum gap between > tracks? What's the biggest BGA package on the board? Are you prepared to > swap pins on the FPGA to aid the routing process? Is your volume enough to > make it worth spending a lot of time on the layout? How fast are your > risetimes and how long are your traces? Do you have Hyperlynx? Are you gonna > insist on a plane for each of your power supplies, or do you know what > you're doing? ;-) > > 256 pin BGA, 4mil tack/gap, uvias, two ground planes, routed powers, > quick(ish) turnaround, long and fast traces = 6 layers, maybe even 4 with > one ground plane if you're quite talented and have a lot of time. > Cheers, Syms. > p.s. Simetry (sic)? Pah, I spit on symmetry. I have laid out my first board using the FT256. I have not had it fabricated yet. It is 4 layers 6/6mil track/space. The real killer was the size of the vias. I used 1 solid groundplane and planelets for VCCIO VCCAUX and VCCCORE. All IO voltages are the same which helps. I was not able to route out all the IO. I have posted a PDF file containing the PCB layers at http://dlharmon.com/dspcard.pdf Any comments on whether or not it will have decent signal integrity would be appreciated. Maybe it can provide some ideas. Darrell Harmon http://dlharmon.comArticle: 85479
Alex Gibson wrote: > John Williams has uclinux working on it. > http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux Credit where credit's due - Paul Hartke did the work, I'm just hosting the files! :) JohnArticle: 85480
Hi all, I am implementing a I2C slave. I am refering XAPP333 for my deisgn. But one of the "limitation" of that reference design from XILINX is that it does not support "clock stretching". Suppose we do not need clock stretching "SCL" will be taken as INPUT to my I2C slave block.But if i want Clock stretching the slave also will be driving the SCL low when required to keep the master on hold.In this case SCL will be an INOUT for my module. My question is how to go about this implementation(tristate buffers on SCL!!!). Waht i am planning to do is, i will pull the SCL line low whenever i want to stop the clock transition on SCL from master else i will drive a "Z" on SCL. please comment on this implementation. Regards, PraveenArticle: 85481
Hi I have made a FIR filter using multipler components and BRAMs But i am facing problems during timing simulation, it works fine during functional simulation. will explain little bit about other components involved in my design In my design i have a 35.328 MHz base clock have multipled it by 2 and used to run another FIR filter (32 tap decimation available from core gen) this is a fixed tap one Now i multipled 70.656 MHz output of my first DCM again by 2 to get 140.312 MHz which is given to the new 32 tap FIR filter i made as described above (ie using descrite components , multipler,BRAM etc) I need to run it at 140.312 Mhz as my input data rate is at 4.416 and the number of tap filters are 32. (i can split it into two 16 tap filter but in that case i need 4 BRAMs for this filter itself, in that case i cannot accomodate other filters which is already existing in my design, as i am currently using xc3s50 device which has got 4 BRAMs only) functionally it simulated well but during timing simulation i am getting this error in my model sim simulator =================================== Time: 9898215 ps Iteration: 3 Instance: /tb_gl/uut/glrx_1_tde_filter_comp_tde_filter1_multiply_comp_bu138 # ** Warning: /X_FF HOLD Low VIOLATION ON I WITH RESPECT TO CLK; # Expected := 0.381 ns; Observed := 0.055 ns; At : 9898.226 ns # Time: 9898226 ps Iteration: 3 Instance: /tb_gl/uut/glrx_1_tde_filter_comp_tde_filter1_multiply_comp_bu142 # ** Warning: /X_FF HOLD High VIOLATION ON I WITH RESPECT TO CLK; # Expected := 0.381 ns; Observed := 0.328 ns; At : 9898.5 ns # Time: 9898500 ps Iteration: 3 Instance: /tb_gl/uut/glrx_1_tde_filter_comp_tde_filter1_multiply_comp_bu152 # ** Warning: /X_FF HOLD High VIOLATION ON I WITH RESPECT TO CLK; ================================== what is this error means. i think there is some set-up violation but how do i debugg this problem how can i see the internal signals during timing simulation ? please advice me in this regard thanks bijoyArticle: 85482
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:newscache$9unuhi$4kd$1@lbox.itee.uq.edu.au... > Alex Gibson wrote: > >> John Williams has uclinux working on it. >> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux > > Credit where credit's due - Paul Hartke did the work, I'm just hosting the > files! :) > > John I thought, Paul had linux running on the v2pro board ? So he got uclinux running as well. Good :-) I'm tempted to buy one of the xupv2p boards myself rather than wait and share the one at uni. Paul Hartke wrote: > Or http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html > > I've already used these helpful references to get a Linux kernel running > on > the PowerPC405 on the Digilent XUP-V2Pro board. I'm new to ucLinux but it > doesn't appear to be much more complicated than the ucLinux steps. > > Paul AlexArticle: 85483
Hi all, I am implementing a SPD interface in an FPGA. The DDR SDRAM is from MICRON. Now to redd the EEPROM content(first 128 bytes) , first i will send the slave addres of EEPROM over I2C(with r/w='1' , which indicates a read).Now my question is will the EEPROM send all the bytes serially at one shot, OR should i address which byte i want to read explicitly ?? Regards, PraveenArticle: 85484
Hi folks, my name is Jens and I am student of the Technical University Berlin. Through my course of study in microelectronics VHDL design is becoming my favorite hobby. My other interests are signal processing and compression in general. Lately I purchased an FPGA Evalution board second-hand (guess where?) and I am now starting my first "private" implementations. Just to give you a short intro... ;-) I am interested in implementing compression algorithms using VHDL on an FPGA. I want to build a data transmission system that compresses portions of the incoming data (not the whole data but "frames" of like 800 bytes) on-the-fly. In my search for a fast (i.e. real-time capable at a "desired" data rate of - let's say - 300 MHZ?) "universal" compression scheme I came across the following stepping stones: - is there any free example code for compression algorithms available in VHDL to get an overview and a first impression of implementation complexity? - what would you think are the most promising algorithms for my purpose (i.e. when statistics and semantics of the input data are unknown), first of all I thought of delta encoding, sorted RLE, LZ, ....? - as the input data is unknown the álgorithm must be lossless, reducing redundancy (if possible), not irrelevancy. what are the theoretical limits of "universal" compression, not emphazizing one particular statistical property (like similar by values in succession)? - what is meant by the keyword "systolic implementations" and "pipeling" in that particular context? I came across that very often lately - what if my code gains different compression ratios for consecutive data portions? surely a FIFO can decouple input and output rate but eventually the FIFO will underflow? Thanks for you help + support in advance, any comments, hints and help is appreciated! Bye Jens P.S.: I'm looking for the standard works "Sayood, Khalid: Introduction to data compression, Academic Press, 199x or 200x" and/or ". Salomon: Data Compression, Springer-Verlag, New York, 200x". Are there any sources of an electronic copy (ps, pfd, etc.) or transcriptions?Article: 85485
Paul Smith wrote:
> Hi,
>
> I need to add a pair of 8 bit (unsigned) integers to get a 9 bit
> (unsigned) result at 250 MHz, preferably in an XC3S50-4.
>
> Using the Coregen adder/subtractor V7 with maximum pipelining (9) and
> RPM on, the best cycle time I can get is 4.55 ns. At each pipeline
> level the critical path is a LUT, a MUXCY, and another LUT.
>
> Can anyone point me at some hints for a faster implementation (besides
> going to a faster part?
>
> TIA
>
> Paul Smith
> Indiana University Physics
Hi,
Another solution is to fully pipeline the adder but it requires that the result
can be pipelined and that you are not area limited.
This solution doesn't use the carry chain but instead doing a normal adder with
one lut for calculate the carry bit and one lut for calculate the result bit.
Each LUT is directly connected to a DFF.
Making it 9 or 10 doesn't change the speed, just the size.
So the critical path is DFF->LUT->DFF which should meet your speed requirement.
The code below is a quick and dirty implementation of this.
It can now do 3 ns now in a Spartan3-4.
It can be improved both in area and speed.
If you want it faster then the LUTS and DFFS needs to be floorplanned using RLOC.
Göran Bilski
library IEEE;
use IEEE.std_logic_1164.all;
entity adder is
generic (
Size : natural := 8);
port (
Clk : in std_logic;
A : in std_logic_vector(Size-1 downto 0);
B : in std_logic_vector(Size-1 downto 0);
Res : out std_logic_vector(Size-1 downto 0)
);
end entity adder;
architecture IMP of adder is
type array_type is array (natural range 0 to Size) of
std_logic_vector(Size-1 downto 0);
signal A_Temp : array_type;
signal B_Temp : array_type;
signal Res_Temp : array_type;
signal Carry : std_logic_vector(Size downto 0);
begin -- architecture IMP
Res_Temp(0) <= (others => '0');
carry(0) <= '0';
All_Bits: for I in 0 to Size-1 generate
Res_Bit : process (Clk) is
begin -- process Res_Bit
if Clk'event and Clk = '1' then -- rising clock edge
A_Temp(I+1) <= A_Temp(I);
B_Temp(I+1) <= B_Temp(I);
Res_Temp(I+1) <= Res_Temp(I);
Res_Temp(I+1)(I) <= A_Temp(I)(I) xor B_Temp(I)(I) xor Carry(I);
Carry(I+1) <= (A_Temp(I)(I) and B_Temp(I)(I)) or
(A_Temp(I)(I) and Carry(I)) or
(B_Temp(I)(I) and Carry(I));
end if;
end process Res_Bit;
end generate All_Bits;
DFFs : process (Clk) is
begin -- process DFFs
if Clk'event and Clk = '1' then -- rising clock edge
A_Temp(0) <= A;
B_Temp(0) <= B;
Res <= Res_Temp(Size);
end if;
end process DFFs;
end architecture IMP;
Article: 85486Paul Smith wrote: > ISE 7.1 defaults to 85 C and 1.14 volts; I thought the idea was that if > a design meets timing under these limits you were safe under "normal" > conditions. No, if the timing meets at these conditions, it is safe to run it at 85°C and 1.14V ... SylvainArticle: 85487
Hello, I use IMPACT to program two FPGAs via a PROM. The PROM is xc18v04 and the FPGAs are xc2S300E-6. Here is the organization of the connections (as on p. 12 of the DS026 document, datasheet of the PROM): Vref and GND pins of the parallel IV cable are connected to 3.3V and ground. TCK and TMS pins of the cable are connected with the PROM and the FPGAs. TDI pin is connected with the PROM. TD0 pin of the PROM is connected with TDI pin of the first FPGA (M2M1M0 =3D 000). TDO pin of the first FPGA is connected with TDI pin of the second FPGA (M2M1M0 =3D 111). TDO pin of the second FPGA is connected with the TDO pin of the parallel IV cable. I build the chain in the PROM formatter (file mode in IMPACT). PROM file generation is successfull. Then I go to device mode, serial mode. The connection to the cable is successfull. If I do not use the wizard, I can only add the .bit files of the FPGAs. If I use the wizard, I can add the mcs file created with the PROM formatter. In both cases, when I try to "program" I get the following error message "DONE pin did not go low". We checked the activity on TCK clock and we only see a down pulse of about 600=B5s. Could you tell me what I have to do in IMPACT to generate the necessary signals to the cable? Thank you, MarieArticle: 85488
In article <ee8ec82.1@webx.sUN8CHnE>, vadimv@ieee.org says... > I also noticed that the fitter for ISE 7.1 isn't as efficient. > I had a legacy design for an XC9500, and I called Xilinx tech > support on an unrelated issue. I was using 6.3, the tech support > guy used 7.1, and he couldn't fit my design to the chip. > He had to install 6.3 to be able to work on it. It really does > seem that the new fitter isn't as efficient. > IMHO, for XC9500 CPLD's it is best to stick with Webpack 5.2. Only yesterday I had a case where I needed to modify an old design slightly and in this occasion I thought to migrate the design to the lastest ISE version. The design failed to work, but in a way that only some signals were wrong. So the failure was not noticed immediately, since some parts of the design worked, but an important function did not. Simply compiling the design with 5.2 brought the design to work. Since this was not the first time I got burned with 7.1 (remember the inverted outputs bug ?), I hope I will learn the lession this time. The story however confirms my opinion that the XC9500 family is a unloved child in Xilinx. Regards KlausArticle: 85489
I'm using the Digilent S3 starter kit, which includes a xcf02 platform flash chip. With the as-shipped test design in the platform flash, it loads automatically on power-up, however when I program my design into the flash chip, it only loads when I push the Prog button on the board. If I reprogram the test design, it auto-loads OK. Is there an option I need to set somewhere to make it auto-load my design from the flash?Article: 85490
Hi, everybody I have a simple question about gated clocks. I remember reading somewhere in this group that "gated clocks are anathema to this group". Can someone explain what is bad about such clocks. Also, I recently read that XST and Quartus perform different timing analyses on paths between flip-flops with gated flops in between (www.altera.com/literature/wp/wp_timingAnalysis.pdf, page 6 - transparent latches): "Using the Xilinx ISE tool, the minimum period analysis may start at or end in latches because the ISE software treats latches as timing points similar to registers. The Quartus II software treats latches as logic and analyzes them as part of a look-up table (LUT) chain. Because of this difference, the register-to register logic level in the timing analysis report is shorter as reported by the ISE software than it is as reported by Quartus II software when latches are involved." Does anybody think that this can be a pitfall? If so, can you give an advice of avoiding it? I am a novice to VHDL and FPGA usage... Thanks and best regards! Stoyan ShopovArticle: 85491
Wondering if anyone else has experienced this.... After the recent X-Fest seminar in Cambridge UK, I ordered the Memex FPGA Design Starter kit on the x-fest special offer, as it was a cheap way to get the BaseX software. I'm now told that the kit won't be shipped til mid-August. I have no problem with that as I don't need the hardware immediately & already have the S3 starter kit.. However when I contacted Memec to ask if they could ship the software immediately (which Incidentally they charged my card for 2 weeks ago), they claimed that this wasn't possible, and when I pressed them they said they'd ask Xilinx but were fairly sure they wouldn't do it. I'm sure I'm not the only one who ordered this offer as it was a very good deal compared to the normal price - has anyone else had any joy getting the software out of them ahead of the hardware ? Seems like a pretty daft situation.....Article: 85492
> Can someone explain what is bad about such clocks They're almost impossible to implement without getting glitches. Use clock enables instead. If your prototyping an ASIC, and can afford it, SynplifyPro will do automatic clock gate to enable conversion. Cheers, JonArticle: 85493
> I remember reading
> somewhere in this group that "gated clocks are anathema to this group".
> Can someone explain what is bad about such clocks.
Short version:
Putting a clock through logic leads to skew, jitter, runt pulses, and lots
of other horrible things. These all make life far harder for the
implementation tools, which work on the assumption that you're not a moron.
FPGA logic fabric was designed for synchronous logic design. If you need to
switch a clock on and off "globally" (e.g. for power saving), some devices
have dedicated "clock multiplexor" resources to do this.
Gate your clocks, and your designs will run slower. Your tools will run
slower. Your designs will stop working inexplicably when they warm up or
cool down. Your logic will cease to work when you buy a new batch of chips.
Your wife will leave you for a younger man and your pot plant will die. Just
don't do it!
-Ben-
P.S. You *really* don't want to hear the long version.
Article: 85494In addition to all the other comments already made there is the basic problem that every time you re-run the build process the timing of the generated clock, relative to it's source, will be different. The result can be a nightmare of the design sometimes working, or not, and if you are very unlucky a half way house between working and not. That said if you are gating (dividing) by using a flip-flop then you can do something in this area. Your generated clock will still differ in timing relationship to the source clock. Factors such as build, silicon batch, voltage, temperature will have a variance on this timing. The only time I would use this is if I had a large design, that had a variable enable function (non regular 1 in N clocks), was also resource critical (tight squeeze in chip), to sit on the (gated) clock. By not using local clock enables you can save some resource.Otherwise I would use a clock enable or something like a DCM to divide, or control, the clock. If you do use a flip-flop control then extreme care will need to be taken in passing signals, or data, between the generated clock domain and source clock domain. All the usual non-related clock domain signal interfacing techniques will need to be used. John Adair Enterpoint Ltd. - Home of MINI-CAN. FPGA CAN Bus Development Board. http://www.enterpoint.co.uk <stoyan.shopov@gmail.com> wrote in message news:1118394731.028676.14960@g47g2000cwa.googlegroups.com... > Hi, everybody > I have a simple question about gated clocks. I remember reading > somewhere in this group that "gated clocks are anathema to this group". > Can someone explain what is bad about such clocks. > Also, I recently read that XST and Quartus perform different timing > analyses on paths between flip-flops with gated flops in between > (www.altera.com/literature/wp/wp_timingAnalysis.pdf, page 6 - > transparent latches): > > "Using the Xilinx ISE tool, the minimum period analysis may start at or > end in latches because the ISE > software treats latches as timing points similar to registers. The > Quartus II software treats latches as logic > and analyzes them as part of a look-up table (LUT) chain. Because of > this difference, the register-to register > logic level in the timing analysis report is shorter as reported by the > ISE software than it is as > reported by Quartus II software when latches are involved." > > Does anybody think that this can be a pitfall? If so, can you give an > advice of avoiding it? I am a novice to VHDL and FPGA usage... > > Thanks and best regards! > Stoyan Shopov >Article: 85495
>If you want to save some coin, you should look at the Lattice EC fpgas. >They have built in DQS & clock domain transfer logic to support DDR >memory up to 200Mhz. Although density is not as large as V4, you can >get up to a 33k or 40k LUT device. Teo, have you tried the IP core from Lattice ? Or are you using the datapath template from the IP Manager ? Rgds Andr=E9Article: 85496
If you just need synthesis, p&r, then ISE Webpack can be used as a stop gap for Spartan-3 devices up to XC3S1500. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Mike Harrison" <mike@whitewing.co.uk> wrote in message news:cenia1pc7q3ptsc4rrhts8phl8085g2smh@4ax.com... > Wondering if anyone else has experienced this.... > After the recent X-Fest seminar in Cambridge UK, I ordered the Memex FPGA > Design Starter kit on the > x-fest special offer, as it was a cheap way to get the BaseX software. > I'm now told that the kit won't be shipped til mid-August. I have no > problem with that as I don't > need the hardware immediately & already have the S3 starter kit.. > > However when I contacted Memec to ask if they could ship the software > immediately (which > Incidentally they charged my card for 2 weeks ago), they claimed that this > wasn't possible, and when > I pressed them they said they'd ask Xilinx but were fairly sure they > wouldn't do it. > > I'm sure I'm not the only one who ordered this offer as it was a very good > deal compared to the > normal price - has anyone else had any joy getting the software out of > them ahead of the hardware ? > > Seems like a pretty daft situation.....Article: 85497
Thanks to all of you, guys, you have been really very helpful! Actually, I suspected there might be glitches when gating a clock, now things are quite more clear.Article: 85498
"Mike Harrison" <mike@whitewing.co.uk> wrote in message
news:cenia1pc7q3ptsc4rrhts8phl8085g2smh@4ax.com...
> Wondering if anyone else has experienced this....
> After the recent X-Fest seminar in Cambridge UK, I ordered the Memex FPGA
Design Starter kit on the
> x-fest special offer, as it was a cheap way to get the BaseX software.
> I'm now told that the kit won't be shipped til mid-August. I have no
problem with that as I don't
> need the hardware immediately & already have the S3 starter kit..
>
> However when I contacted Memec to ask if they could ship the software
immediately (which
> Incidentally they charged my card for 2 weeks ago), they claimed that this
wasn't possible, and when
> I pressed them they said they'd ask Xilinx but were fairly sure they
wouldn't do it.
>
> I'm sure I'm not the only one who ordered this offer as it was a very good
deal compared to the
> normal price - has anyone else had any joy getting the software out of
them ahead of the hardware ?
>
> Seems like a pretty daft situation.....
Same deal downunder, Mike,
I'm making do with a 60 day version of the software while waiting, which
the local FAE has promised to refresh for me if the kit takes too long.
Cheers
--
Alf
alfkatz@remove.the.obvious.ieee.org.y,
Article: 85499
Hi
I am using a spartan3 development board and trying to learn about
MicroBlaze.
My application is simple, I want the bitpattern at the slideswitches
to appear on the leds (The board has 8 slideswitches and 8 leds).
If I use the BSB to create my MicroBlaze it works fine.
the modules (in Add/Edit cores) the BSB create/use is:
microblaze 4.00.a microblaze_0
opb_mdm 2.00.a debug_module
lmb_bram_if_cntrl 1.00.b dlmb_cntlr
lmb_bram_if_cntrl 1.00.b ilmb_cntlr
bram_block 1.00.a lmb_bram
opb_gpio 3.01.b LEDs_8Bit
opb_gpio 3.01.b DIP_Switches_8Bit
dcm_module 1.00.a dcm_0
If I make one from scratch it doesn't work.
the module (in Add/Edit cores) I create/use is:
lmb_bram_if_cntrl 1.00.b i_bram
lmb_bram_if_cntrl 1.00.b d_bram
bram_block 1.00.a bram
opb_gpio 3.01.b Switch
microblaze 4.00.a MyProsessor
opb_gpio 3.01.b Leds
dcm_module 1.00.a dcm_0
and my c-code is simple (used on both):
#include "xparameters.h"
#include "xgpio_l.h"
int main()
{
unsigned char ucData;
while(1)
{
// read from slide switches.
ucData = XGpio_mGetDataReg(SWITCH BASEADDR, 1);
// put value in LEDs
XGpio_mSetDataReg(LEDS BASEADDR, 1, ucData);
}
return 0;
}
The BASEADDR are from the headers xparameters.h in the respective
projects.
BSBs ucf file look like this:
Net sys_clk_pin LOC=T9;
Net sys_rst_pin LOC=l14;
## System level constraints
Net sys_clk_pin TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 20000 ps;
Net sys_rst_pin TIG;
## FPGA pin constraints
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<0> LOC=k12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<1> LOC=p14;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<2> LOC=l12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<3> LOC=n14;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<4> LOC=p13;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<5> LOC=n12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<6> LOC=p12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<7> LOC=p11;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<0> LOC=k13;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<1> LOC=k14;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<2> LOC=j13;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<3> LOC=j14;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<4> LOC=h13;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<5> LOC=h14;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<6> LOC=g12;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<7> LOC=f12;
My ucf file look like this:
NET "sys_reset" LOC = "L14" ;
NET "sys_clock" LOC = "T9" ;
NET "Leds_GPIO_d_out<0>" LOC = "K12" ;
NET "Leds_GPIO_d_out<1>" LOC = "P14" ;
NET "Leds_GPIO_d_out<2>" LOC = "L12" ;
NET "Leds_GPIO_d_out<3>" LOC = "N14" ;
NET "Leds_GPIO_d_out<4>" LOC = "P13" ;
NET "Leds_GPIO_d_out<5>" LOC = "N12" ;
NET "Leds_GPIO_d_out<6>" LOC = "P12" ;
NET "Leds_GPIO_d_out<7>" LOC = "P11" ;
NET "Switch_GPIO_in<0>" LOC = "F12" ;
NET "Switch_GPIO_in<1>" LOC = "G12" ;
NET "Switch_GPIO_in<2>" LOC = "H14" ;
NET "Switch_GPIO_in<3>" LOC = "H13" ;
NET "Switch_GPIO_in<4>" LOC = "J14" ;
NET "Switch_GPIO_in<5>" LOC = "J13" ;
NET "Switch_GPIO_in<6>" LOC = "K14" ;
NET "Switch_GPIO_in<7>" LOC = "K13" ;
This problem is realy getting annoying, there must be something
essential I have been overlooked.
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