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
Thanks for the answer, Daniel! That helps a lot. I pretty much have to work with what I have on this dev board, so unfortunately I can't consider switching to bigger S3 devices. Also, when I was doing this in my head I underestimated the amount of memory I'd need.. it's actually quite a bit higher, meaning even the bigger devices wouldn't do it with on-chip memory. This is ok, I have an external 8Mx16 SRAM at my disposal, the minor issue being that it's single port. I was hoping to avoid having to devise an efficient way to read/write data with that RAM chip, but it looks like this is what I'll have to do anyway... Thanks again! Steve Daniel S. wrote: > Steve Battazzo wrote: >> I would like to make a dual-port RAM inside my FPGA... >> I am using a Spartan 3 1000K gate model... >> I know it takes a pretty good number of macrocells to do this but I >> don't quite know enough on the low level of the architecture of a >> macrocell to understand what the limitations are. >> If possible I would like to have about 60KB of memory, in the form of >> 30K x 16. > > Look at the product guides for the Spartan 3(E)... > > http://www.xilinx.com/products/silicon_solutions/fpgas/spartan_series/spartan3_fpgas/overview.htm#s3table > > http://www.xilinx.com/products/silicon_solutions/fpgas/spartan_series/spartan3e_fpgas/overview.htm#s3eTable > > > With the XC3S1000, you get 432kbits of Block RAM (384kbits usable in x16 > configuration) and 120kbits of distributed RAM. To achieve 30Kx16, you > need at least 480kbits - this practically means consuming the whole FPGA > as a single RAM with nearly no room left for other functionality, > assuming the extra logic needed to manage the distributed memory still > fits. More likely than not, you will need to step up - the XC3S1200E > would be the smallest S3 FPGA that could definitely fit this RAM with > some room to spare. > > Since large distributed memories have significant logic footprint > (muxes, control signal fan-out, etc.) combined with either long access > latencies (input + output pipelining) or slow performance (large > non-pipelined muxes and decoders), you will have to look at the XC3S1500 > or XC3S1600E if you need your memory to be fast and low-latency: these > are the two smallest S3 devices that can implement your RAM entirely > within Block RAMs.Article: 117976
On Sat, 14 Apr 2007 23:33:11 -0400, "Daniel S."
<digitalmastrmind_no_spam@hotmail.com> wrote:
>Explicitly laying down as many of the registers from an RTL design as
>possible is a nearly universally accepted design practice
Not "universally accepted" by me. I don't like designing
netlists. I have synthesis tools to do that for me.
I also, of course, reserve the right to design a netlist
when it suits my purpose - in particular, for certain
corners of a design where procedural code is not a
clear description of what's going on, and a structural
description makes more sense. Those places are few.
> It also cuts down on the
>number of nameless nets in the output.
I don't really see this as relevant. *Any* design will have
many renamed nets after synthesis.
>What sort and how much of this code simplification are we talking about?
>For the stuff I can think of, it simply boils down to splitting the
>combinational and register parts...
Here are my key reasons for using variables and heavily
procedural descriptions of logic:
1) Variables that represent intermediate subexpressions
in combinational logic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Useful in both combinational and sequential processes.
Pre-calculating a complicated subexpression is often useful
for the sake of code clarity, and may also be useful as
an optimisation hint. Here's an example from something
I wrote yesterday (in Verilog, but you get the idea):
//
dont_relinquish = 0;
// find what the most recent requester wants
req_A = 0;
req_W = 0;
if (last_master[0]) begin
req_A = M0_ADDR;
req_W = M0_WRITE;
end else if (last_master[1]) begin
req_A = M1_ADDR;
req_W = M1_WRITE;
end
// any reason why the current master must stay in control?
if (back_to_back) begin
if ( atomic_bursts
&& (req_A == last_addr + 1'b1)
&& (req_W == last_write)
)
// next step in a burst transfer
dont_relinquish = 1;
if ( atomic_rmw
&& (req_A == last_addr)
&& req_W && !last_write
)
// next step of a read-modify-write
dont_relinquish = 1;
end
if (!dont_relinquish)
// start arbitration for a new master...
//
Variables dont_relinquish, req_A, req_W (and many others)
are relevant only within this clocked process. Without
them, the final "if" test in this code snippet would have
been grotesque. If those variables had instead been signals,
they would have unacceptably cluttered the declaration of
the architecture and required another process (or continuous
assignment) to compute them. As variables they can be hidden
in the process, where they belong. By giving these variables
a new value at the start of the process, as I've done
here, I can be entirely confident that they synthesise
to combinational logic with neither latch nor flipflop.
2) Variables that represent internal state of a process,
not relevant to the rest of the architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Similar idea to (1), but using the value calculated on
a previous pass through the clocked process - so the
variable synthesises to a flop Variables "last_write",
"last_addr" and "back_to_back" in my code fragment
(above) work like this. Again I don't want
the top level of my architecture cluttered with signals
that are relevant only to a single process. (Admittedly
you can do that with VHDL BLOCKs as well, but it's much
harder work.)
3) Visibility of next-state value
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here's a paraphrase of how I prefer to write state
machines with registered outputs:
process (clock, reset)
variable state: state_type;
begin
if reset = '1' then
state := idle;
outputs <= default_values;
elsif rising_edge(clock) then
--- calculate next state
case state is
when idle =>
if start = '1' then
state := run;
end if;
...
end case;
--- variable "state" now holds NEXT-state value
--- calculate outputs
case state is
when idle =>
outputs <= default_values;
when run =>
outputs <= ...
...
end case;
end if;
end process;
With a single variable "state" I have easily been able
to capture both the stored state value and the next-state
value. The two case statements exactly correspond to
the state transition diagram. The state vector is hidden
in the state machine process, where it belongs. Had I
used signals I would have been obliged to declare both
state and next-state as signals, polluting the architecture.
None of these idioms causes any difficulty for any
synthesis tool I have encountered, with the dishonourable
exception of one Verilog synthesis tool, aimed at the ASIC
market, which is not much used these days.
Mike Treseler has elegantly argued in this forum for
even more radical use of variables than I've described
here. I am not totally persuaded by his arguments,
since I like the flexibility, and natural description of
parallelism, that multiple processes can give me.
Both of us can write designs and testbenches that work,
so (I think!) we are each happy to accept and respect
the other's viewpoint. Like any matter of style, you
have a choice and I must accept your choice; it's clear
that everything I have described here could instead be
done with signals.
I'd ask you to remember, though, that everything you
can do in C++ can be done in C, and everything you
can do in C can be done in assembler, and everything
you can do in assembler can be done in raw binary
machine code. I know where I want to be on that scale.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 117977On 13 Apr., 15:22, David Brown <d...@westcontrol.removethisbit.com> wrote: > (It's easier to follow threads if you quote appropriately - if you want > to use Google's broken Usenet interface, you have to learn the tricks.) Hello David! Sorry for not quoting. I hope this times it works. > It's a while since I did any FPGA stuff, but as far as I know, the web > edition fully supports the whole Max7000 series. The source code for > the configuration controller in the EPM7128 is available along with the > NIOS development kit (although it's easy enough to write your own). Now, I figured out that there is no appropriate configuration chip for the Stratix device on my board. But I also figured out, that the EPM7128, the FPGA and the Web Interface of the NIOS implementation on the FPGA together give me the opprtunity to use this board as FPGA dev Kit (I'm not interested in NIOS, yet). So I can load the VHDL configurations I made with Quartus II (.hexout file) into the configuration flash memory via the Web Interface that comes with the board. Now I understand, that I don't need any flash functionality of Quartus II, when I use this board. > If you are thinking about making your own boards, the EPM7128 is a silly > choice - it's expensive and limited, and completely unnecessary with > more modern FPGAs. You are right! In the case of an own board I would use the appropriate configuration chip for the chosen FPGA device. I think, the guys from Altera used the EPM7128 because they needed some custom functions for this dev board, and because this chip was state of the art at the time, they build it. Slowly, I get an idea of using this board and Quartus II . . . Greets MaikArticle: 117978
Jonathan Bromley wrote: > >> It also cuts down on the >> number of nameless nets in the output. > > I don't really see this as relevant. *Any* design will have > many renamed nets after synthesis. I only said that being more explicit reduces that number, not prevent any from appearing. >> What sort and how much of this code simplification are we talking about? >> For the stuff I can think of, it simply boils down to splitting the >> combinational and register parts... > > Here are my key reasons for using variables and heavily > procedural descriptions of logic: > > 1) Variables that represent intermediate subexpressions > in combinational logic > > 2) Variables that represent internal state of a process, > not relevant to the rest of the architecture These two sound a lot like two sides of the "keep related code together" coin. For the synchronous stuff, VHDL allows local signals. > 3) Visibility of next-state value > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Here's a paraphrase of how I prefer to write state > machines with registered outputs: > > process (clock, reset) > variable state: state_type; > begin > if reset = '1' then > state := idle; > outputs <= default_values; > elsif rising_edge(clock) then > --- calculate next state > case state is > when idle => > if start = '1' then > state := run; > end if; > ... > end case; > --- variable "state" now holds NEXT-state value > --- calculate outputs > case state is > when idle => > outputs <= default_values; > when run => > outputs <= ... > ... > end case; > end if; > end process; > > With a single variable "state" I have easily been able > to capture both the stored state value and the next-state > value. The two case statements exactly correspond to > the state transition diagram. The state vector is hidden > in the state machine process, where it belongs. Had I > used signals I would have been obliged to declare both > state and next-state as signals, polluting the architecture. Looks to me like you are adding the state machine's delay to all your output logic by doing this way... I do similar stuff but design the pipeline to account for the cycle delay between the state machine and synchronous output logic to shave nanoseconds off my delays, no need to pollute the architecture with a 'next state' signal here but it does make other things (like flow control) trickier. > I'd ask you to remember, though, that everything you > can do in C++ can be done in C, and everything you > can do in C can be done in assembler, and everything > you can do in assembler can be done in raw binary > machine code. I know where I want to be on that scale. The distance between using modular signals and local variables is very short and in now way comparable to the effort level between C/C++ and ASM/bin... different coding styles != significantly different effort. But yes, in the end only the final results matter.Article: 117979
On Sun, 15 Apr 2007 11:50:56 -0400, "Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote: ... > These two sound a lot like two sides of the > "keep related code together" coin. Absolutely. The single most important contributor to readable, maintainable code in *any* language, especially when combined with "keep irrelevant stuff hidden". > For the synchronous stuff, VHDL allows local signals. Really? Only in blocks and generates, I think. Personally I find blocks to be clumsy and hard work, and there are surely more synth tools that have trouble with blocks than have trouble with variables. [...] >Looks to me like you are adding the state machine's delay to all your >output logic by doing this way... Indeed so. It is not usually a problem, as FSM output decoding logic tends to be rather simple. But I agree that this is an issue that needs to be watched. > I do similar stuff but design the >pipeline to account for the cycle delay between the state machine and >synchronous output logic to shave nanoseconds off my delays, no need to >pollute the architecture with a 'next state' signal here but it does make >other things (like flow control) trickier. Pipeline control is always tricky. The big benefit I perceive in "my" coding style for FSMs is that it faithfully preserves the logic of the state diagram, in a very maintainable way, whilst adding output registers for free. I certainly don't dispute that sometimes you have to do special tweaks to the RTL to achieve timing goals. [...] >But yes, in the end only the final results matter. Sure; and, as I was at some pains to say, I'm moderately happy to agree to differ. And, of course, whatever I say about coding styles and idioms, I'll always find a situation where I prefer - or need - to break my own guidelines. Thanks -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 117980
Hallo, has anybody some pin count requirements for the Latticemico32? I know, it depends heavily on the choosen combination, so information to the configuration is welcome. CLB Requirements would also be fine. Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 117981
Un bel giorno Jonathan Bromley digiṭ:
> This is simply untrue. They give completely different results. [...]
You are right, probably I made some confusion with the various tests. I
tried again, and the post-translated model gave the expected results in
both cases (increment before and increment after).
Anyway, I'm still very skeptical about the use of variables in synchronous
designs. Take some code like this:
variable x: integer:=1;
[...]
x := x*(x+1);
if x<threshold_1 then
actions...
end if;
x := x*(x+1);
if x<threshold_2 then
actions...
end if;
x := x*(x+1);
if x<threshold_2 then
actions...
end if;
etc...
The strong advantage of synchronous designs is that the maximum clock rate
is limited only by the maximum delay path; when you use the variables (that
have to be evaluated immediately), you have to *sum* the times of all the
related delay paths! It looks very inefficient.
--
emboliaschizoide.splinder.com
Article: 117982
Daniel S. wrote:
> The distance between using modular signals and local variables is very
> short and in no way comparable to the effort level between C/C++ and
> ASM/bin... different coding styles != significantly different effort.
Variables in a single process provide an abstraction
that I have not been able to duplicate
using signals in a single architecture.
Sometimes I like to suspend time in order
to describe value creation by successive approximation.
Let say I want to describe a phase accumulator
in the traditional manner.
With a multi-process design, I might
say something like:
accum_s <= '0' & accum_s(accum_s'length - 2 downto 0)
+ ('0' & addend_c);
in one process and pick up the
output msb in another process:
msb <= accum_s(accum_s'length - 1);
Nothing wrong with this description,
but it requires me to form a little schematic
in my head and to think about two points
in time at once. I have to run a sim
before I am sure I have it right.
Here is a single process description
that does exactly the same thing without
an extra gate, flop or nanosecond:
...
accum_v := accum_v + addend_c; -- add magic number
msb_v := accum_v(accum_v'length-1); -- save the carry bit
accum_v(accum_v'length-1) := '0'; -- clear carry for next time
...
-- Now use msb_v however I like down here ...
With this sort of description, I can sit in
a recliner chair with a listing and a red pen and make useful
additions and optimizations that most often
work the first time.
I am still amazed that synthesis can work out
the gates and flops from this sort of description,
but the fact is that it can, and has for me
for the last five years.
> But yes, in the end only the final results matter.
Indeed.
Everyone's brain is wired up a little differently and
I don't touch working code unless I have to.
-- Mike Treseler
Article: 117983Hi! I have a [MCU] core running at 50MHz which I use for generating patterns/reading status of some other logic, mapped on the same fpga (spartan3). I have noticed the timing after placement/routing is varying with incremental changes; just changing an initial value could make the timing to fail (I saw numbers like 47 and 45 MHz). The logic seems to run on my board but that does not mean it will not fail on some other board/fpga chip. My guess is everything is caused by a difference in the placement; from time to time the placer starts from the wrong place [seed?] and the resulting design will fail timing. Loading the design in fpga_editor I can see different arrangements for the BRAM blocks the design is using (5 out of 12 available). Did you have similar experiences? What can one do to expect more consistent results? I am using Webpack 9.1(0.2). I don't think Webpack version is relevant, I seem to remember same thing with 7.1 version. -- mmihai http://www.delajii.net/consultingArticle: 117984
dalai lamah wrote:
> Anyway, I'm still very skeptical about the use of variables
I was skeptical as well, until I found some good examples
and tried them with my own tools.
> Take some code like this:
> variable x: integer:=1;
Note that variables must be declared
inside a process.
Initialization is useful for simulation,
but variables need to be reset for synthesis.
______________
my_process: process(reset, clock) is
variable x: integer;
begin
if reset = '1' then
x := 1;
elsif rising_edge(clock) then
______________
> [...]
> x := x*(x+1);
> if x<threshold_1 then
> actions...
> end if;
> x := x*(x+1);
> if x<threshold_2 then
> actions...
> end if;
> x := x*(x+1);
> if x<threshold_2 then
> actions...
> end if;
> etc...
Synthesis creates a new node
and a new block of logic each time
a variable is updated.
I sometimes use this feature to
"show my work" in creating a complex value,
but I have never found a reason to
use the intermediate values as in
the example above.
I update each variable once per clock tick
using a template like this:
-------------------------------------------------------------------------------
-- Process Template -- Always exactly the same:
-------------------------------------------------------------------------------
begin -- process template
if reset = '1' then -- Assumes synched trailing edge reset
init_regs; -- procedure
elsif rising_edge(clock) then
update_regs; -- procedure
end if; -- Synchronous init optional
update_ports; -- procedure
end process sync_template;
end architecture synth;
-------------------------------------------------------------------------------
Most variables are internal registers
but others have their values assigned
to a port once per clock tick.
> The strong advantage of synchronous designs is that the maximum clock rate
> is limited only by the maximum delay path; when you use the variables (that
> have to be evaluated immediately), you have to *sum* the times of all the
> related delay paths! It looks very inefficient.
I have not found this to be the case.
All I can say is try it and see.
-- Mike Treseler
Article: 117985Hi, I was wondering how the number 166Mhz for DDR came up? Why not say... 200MHz/250MHz DDR? I am sure there is some thought process behind that, could someone help me walk through? Thanks in advance ! -RohitArticle: 117986
Hi all, I am trying to make a peripheral attached to the OPB bus. This peripheral has a BRAM block in it. The idea is to check how to read and write to the simple BRAM block and later add some logic to the controller. The data to be written to an address range is written to the BRAM block and data is read when needed by the program (this is what we are trying to implement). We would greatly appreciate any information as to how to go about interpreting the signals on the OPB and also how to write / read the data in the BRAM as per the requests on OPB. Thanks and Regards, BhanuArticle: 117987
I would like to know if you have used the High speed FPGA Tranceivers for source synchronous bus application. In my application, I have 20 bit outgoing and 20 bit incoming bus. Is it possible to do bit to forwarded clock alignement, I was thinking about using precision delay element of 5 ns resolutoin with dynamic range of 3 ns. The data rate I am trying to reach is 6.375 Gbps. Altera Stratix2 GX supports 20 transceivers at 6.375 Gbps. I would like to get your feedback and share your experienceArticle: 117988
I've been trying to launch ISE (9.1SP3) and I get this error FATAL_ERROR:Portability:Port_ExecLoaderInit.c:117:1.4 - The executable </home/bjrosen/_pn> can't be found. The installation was not complete. Process will terminate. For more information on this error, please consult the Answers Database or open a WebCase with this project attached at http://www.xilinx.com/support. If I launch it from the $XILINX/bin/lin directory it works fine so it would appear to be some sort of search path problem but I've got everything in my paths, echo $PATH /usr/local/tools/Xilinx/bin/lin:/usr/local/tools/Xilinx/java/lin/jre/bin:/ usr/local/tools/Xilinx/chipscope/bin/lin:/usr/local/tools/Xilinx/bin/ lin64:.:/usr/local/tools/flexlm/bin:/usr/java/jre1.5.0_02/bin:/usr/local/ tools/hdlmaker_lib/i686/bin:/usr/local/tools/hdlmaker_lib/csh:/usr/local/ tools/jre1.5.0_10/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/bin:/usr/ X11R6/bin:/usr/local/csh:/usr/local/sbin:/usr/local/tools/acrobat/bin:/ usr/local/tools/nc_sim/tools/bin echo $LD_LIBRARY_PATH /usr/local/tools/Xilinx/bin/lin:/usr/local/tools/Xilinx/java/lin/jre/lib:/ usr/local/tools/Xilinx/lib:/usr/local/tools/Xilinx/chipscope/bin/lin:/usr/ lib:/usr/local/lib:/usr/X11R6/lib:/usr/lib/xemacs:/usr/local/tools/ jre1.5.0_10/lib echo $XILINX /usr/local/tools/Xilinx Is there some missing variable that I need to set.Article: 117989
If you use opb_bram_if_cntlr to attach BRAMs to opb bus it will use only one port. The other port can be used to interface with your logic. -Sovan.Article: 117990
In article <evtjoo$fpr$1@lnx107.hrz.tu-darmstadt.de>, Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: > Hallo, > > has anybody some pin count requirements for the Latticemico32? I know, it > depends heavily on the choosen combination, so information to the > configuration is welcome. > > CLB Requirements would also be fine. I'm playing with the mico32 ported to Virtex on http://www.microfpga.com/joomla/index.php?option=com_remository&Itemid=2 7&func=select&id=2 and now running on the Spartan 3E starter kit board. That particular project has only 8 output bits (plus power, ground and clock). It has 1k x 32 of BRAM and the only peripheral is a GPIO. Resource usage on the Spartan 3E is: 825 slice flipflops 1513 LUTs 162k equivalent gate count 70 MHz maximum clock frequency -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 117991
hi could you please explain wht is to be coded in combinatorial and wht to be coded in sequential. am bit confused Thanks and Regards lokeshArticle: 117992
On Apr 15, 9:33 pm, rohit20...@yahoo.com wrote: > Hi, > > I was wondering how the number 166Mhz for DDR came up? Why not say... > 200MHz/250MHz DDR? I am sure there is some thought process behind > that, could someone help me walk through? > > Thanks in advance ! > -Rohit 250MHz DDR: http://www.heise.de/preisvergleich/a174535.html 200MHz DDR http://dealnews.com/memory/prices/PC1600-DDR-200-MHz/10/512MB.html 450MHz DDR http://forums.macrumors.com/showthread.php?p=174710 We use 312.5MHz DDR in one of our projects. So what the f**k are you talking about? Kolja SulimmaArticle: 117993
David M. Palmer <dmpalmer@email.com> wrote: > In article <evtjoo$fpr$1@lnx107.hrz.tu-darmstadt.de>, Uwe Bonnes > <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: > > Hallo, > > > > has anybody some pin count requirements for the Latticemico32? I know, it > > depends heavily on the choosen combination, so information to the > > configuration is welcome. > > > > CLB Requirements would also be fine. > I'm playing with the mico32 ported to Virtex on > http://www.microfpga.com/joomla/index.php?option=com_remository&Itemid=2 > 7&func=select&id=2 > and now running on the Spartan 3E starter kit board. > That particular project has only 8 output bits (plus power, ground and > clock). It has 1k x 32 of BRAM and the only peripheral is a GPIO. > Resource usage on the Spartan 3E is: > 825 slice flipflops > 1513 LUTs > 162k equivalent gate count I tried to run the ISE-8 project on ISE9.1 and ISE crashed. Annti's documentation is more then compact and I didn't succeed to recreate a project for ISE-9, not understanding the what was needed around some schematic component. Do you run on ISE-9? Are you willing to give away your project file? Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 117994
Hi all, I am looking for an OPB to wishbone bridge to let OPB talk to my IP via wishbone in EDK. I have read some posts on OPB-> wishbone wrapper (available at opencores.org). Had a look at the wrapper, which raises a couple of questions in my mind. Where is the OPB bus translation to wishbone bus taking place in this wrapper? How to use it in an environment where the IP is connected to the wishbone slave and the wishbone slave has to be read and written by the OPB from the microblaze side? To start with, lets take the example that the wishbone slave is connected to SRAM at the other end and the microblaze writes and reads the SRAM via opb-> wishbone interface. In this scenario, how would this opb->wishbone wrapper help. will be waiting for a reply................ FarhanArticle: 117995
Hi All, I am using the Xilinx Core Genenator to generate the FFT core for my design. But when I tried to simulate with a random noise input with N = 128, the output xk_re and xk_im are all between -5 and 5 which is obviously not the correct result. Matlab result show the fft output in order of 100. I used fixed length of 128 and tried Radix-4 and Radix-2 implemenation options with 16bit data, 16 bit phase factor and scaled options. The output is in natural order. But all of these settings produce the same result. I checked the input and out signals, they seem to be all correct. There must be something I missed here but I just could not figure out now. I would greatly appreciate it if anybody help! Thanks a lot! Regards, WilliamArticle: 117996
I want to design a prototype of SDIO peripheral card which is enabled with GPS function. But I have no experience in SDIO card design. Who can provide me a reference sample? Thanks a lot.Article: 117997
hi all,
can anyone tell me where i can get a free vpw/pwm controller
either in vhdl or verilog according to j1850 standards.
thanks ,
asha.
Article: 117998On 16 Apr., 10:31, "Nokia_E61i : I am waiting for you!!!!!!" <zhy.sh...@gmail.com> wrote: > I want to design a prototype of SDIO peripheral card which is enabled > with GPS function. But I have no experience in SDIO card design. > > Who can provide me a reference sample? > > Thanks a lot. i have a proto-type quality SD card side ip, that could be used as starting point. or you can of course buy the IP from arazan if your budget allows AnttiArticle: 117999
Hi,
I build a IPIF master with Create/Import Peripheral.
I try the example write in the user_logic.vhd:
-- Here's an example procedure in your software application to
initiate a 4-byte
-- write operation (single data beat) of this master model:
-- 1. write 0x40 to the control register
-- 2. write the source data address (local) to the ip2ip register
-- 3. write the destination address (remote) to the ip2bus
register
-- - note: this address will be put on the target bus address
line
-- 4. write 0x0004 to the length register
-- 5. write valid byte lane value to the be register
-- - note: this value must be aligned with ip2bus address
-- 6. write 0x0a to the go register, this will start the write
operation
My C:
#include "xparameters.h"
#include "xutil.h"
int main (void) {
volatile Xuint32* Data;
Data=3D(Xuint32*) XPAR_IPIF_MASTER_0_BASEADDR;
// contr=F4l register
Data=3D(Xuint32*)(0x00+0x00);
*(Data)=3D0x40;
// source address
Data=3D(Xuint32*)(0x00+0x04);
*(Data)=3DXPAR_TEST_0_BASEADDR;
//destination address
Data=3D(Xuint32*)(0x00+0x04);
*(Data)=3DXPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR;
// lengh register
Data=3D(Xuint32*)(0x00+0x04);
*(Data)=3D0x04;
// BE register
Data=3D(Xuint32*)(0x00+0x02);
*(Data)=3D0xFF;
// Go register
Data=3D(Xuint32*)(0x00+0x01);
*(Data)=3D0x0A;
return 0;
}
I put one data in my TEST block, but nothing happened.
I want to transfer the data from the TEST block to a BRAM with this
IPIF, but i don't understand
what address i need to put in my TEST block to access to my BRAM.
Can you help me ????
Thanks
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