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
På Thu, 04 Dec 2003 13:23:55 +0100, skrev Christian Haase <nospams@today.de>: > Hello Fred, > > reading the sites that you find at > http://toolbox.xilinx.com/docsan/xilinx5/manuals.htm > makes you probably forget your questions :0) > > Christian > Just what I was looking for. Thanks a lot :-)Article: 63801
For one, it buys me time -- I don't have to learn cheesy Windows batch files and can use something that is far more flexible and platform independent. Two, it buys integration with the rest of a project. I can run a complete build that includes FPGA stuff (several variants, for example), the C code on an embedded processor, and the C code for Windows/Linux interfaces that may accompany a project. Unfortunately, most of the Xilinx project has to be rebuilt for any change anyhow, so you gain less in terms of incremental build as you do in C projects. Jake "Ken" <aeu96186@NOSPAM.yahoo.co.uk> wrote in message news:<retzb.16505$lm1.134567@wards.force9.net>... > What does 'make' do for you that batch files to run the tools doesn't? > > Not being aggressive - just curious in case I am missing out on some labour > saving functionality! > > Cheers, > > Ken >Article: 63802
Yes, I've used Cygwin extensively for years and like it very much. I was curious if there was a tolerable 100%-Windows environment. "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message news:<2mpzb.292233$275.1013866@attbi_s53>... > I don't use the Navigator. I just make little batch files and execute them > from the command line. I'm told that the Cygwin environment is very nice; > it allows Unix-like shells on Windows, but I haven't tried it. > -KevinArticle: 63803
Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3FCE28FD.7000408@flukenetworks.com>... > Consider adding linux with dual boot for windows. > Then you can use any shell you like > and the real make. Yes, with the new tools usable under Linux, I've considered moving back there. I use Linux under VMWare for a lot of stuff, I just haven't moved my FPGA work back. Maybe that's what I should do...Article: 63804
Hi, Could anyone explain the meaning of the process_table parameter in the mss file (when using the xilkernel). I have a bootloader with the following stuff in the mss file: BEGIN LIBRARY PARAMETER LIBRARY_NAME = xilkernel PARAMETER LIBRARY_VER = 1.00.a PARAMETER MAX_PROCS = 1 PARAMETER PROCESS_TABLE = ((0xA0000000, 1)) PARAMETER CONFIG_THREAD_SUPPORT = true PARAMETER MAX_THREADS = 2 PARAMETER THREAD_STACK_SIZE = 0x100 PARAMETER CONFIG_SEMA = true PARAMETER MAX_SEMA = 1 END Besides that, I have an application (with his own makefile) which should be run from address 0xA0000000, so in the makefile I use the linker option LFLAGS = -xl-mode-xilkernel -Wl,-defsym -Wl,_TEXT_START_ADDR=0xA0000000 When I disassemble the .elf file of the application, it's all ok (addresses starts from 0xA0000000). So what is the meaning of the address in the process_table parameter in the mss file of the bootloader?? Does it make any sense? Or do I not need the process stuff at all, but just use the thread parameters (I only want an application which contains two threads)?! Thanks, FrankArticle: 63805
Using Xilinx ISE 6.1i, FPGA Editor, it is possible to
edit different aspects of the design implementation
directly in the .ncd-file after finishing P&R.
Say you have a huge design, that takes forever to run
P&R on, is it then possible to make small changes in
the .ncd-file, using the FPGA Editor, and then either
generate programming files or create a simulation model
of it, without running P&R first?
The changes I'm talking about, is moving pin-locations,
moving components between slices and last but not least,
editing PULLUP/PULLDOWN on pins. I know I can do this in
the .ucf og .pcf files, but then I will definately need
to rerun P&R, and I want to avoid that.
I trid to introduce PULLDOWN on a pin in a test design
just now, and after I did that, I generated a new Post
P&R sim model, and ran Modelsim. But nothing happened.
Then I noticed that the file I was actually editing when
I had double clicked "View/Edit Routed Design (FPGA Editor)"
under the "Place & Route" node in Xilinx Project Navigator
was the map_<filename>.ncd file, and not the <filename>.ncd.
So I trid to open the <filename>.ncd directly from FPGA Editor,
and did the changes there. When I then generated the new
Post P&R sim model, I got this warning:
WARNING:Anno:13 - The .ncd is out of sync (not logically equivalent) with
the
.ngm; therefore, an .nga will be created from the .ncd.
I have tried to find out what this actually means, but I'm new
to this, so I haven't figured it out yet. Anyway, when I then
started the post P&R simulation with Modelsim, the PULLDOWN
was in effect.
When I tried to generate programming files, I could do that wihtout
any warnings. But since I havent actually downloaded my code to an
FPGA, and meassured the voltage on the actual pin, I'm not really
sure weather my modification works or not.
If anyone has had experience with doing this kind of modifications
without rerunning P&R, I'd like to hear about it. But any comments
are welcome :-)
Sincerely
-Fred
Article: 63806
remove digits wrote:
> Marc Randolph wrote:
>
>> Gernot Koch wrote:
>>
>>> module int_fb(clki, clko);
>>> assign clko = clk_fb;
>>> IBUFG ibufg0(.I(clki), .o(clki_buf));
>>> DCM dcm0(.CLKIN(clki_buf), .CLKFB(clk_fb), .CLK2X(clk_2x));
>>> BUFG bufg0(.I(clk_2x), .O(clk_fb));
>>>
>>> Which wires are phase-aligned clocks here?
>>
>> The output of the BUFG (clk_fb) will be phase aligned with your input
>> clock (clki). By connecting to the CLKFB input, the DCM removes the
>> phase offset introduced by routing, the BUFG, and the DCM itself.
>>
>> This results in the rising edge internal to the FPGA occurring at
>> nearly the same time as the rising edge of the clock feeding the
>> FPGA... hence you maintain a completely synchronous system.
>
> So it makes the board clock synchrounous to the internal clock. Can I
> use the CLK0 output of the DCM at the same time if I need both clock
> speeds inside the FPGA. Will both CLK0 and CLK2X then be phase aligned
> with clki?
Yes, all outputs of the DCM that are multiples of the input clock will
be phase aligned.
>> The first two hits when typing in DESKEW_ADJUST in the Xilinx search
>> page seem to explain it pretty well:
>>
>> http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/cgd/cgd0086_39.html
>>
>> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14743
>
> Well, I had seen those. However, they are quite vague about the effect
> of the DESKEW_ADJUST setting. I did not understand what precisely
> happens if you set that to SOURCE_SYNC vs. SYSTEM_SYNC. Nor is there any
> information what the other possible settings will result in. E.g. what
> would happen in the example above (internal feedback) if I choose one
> setting vs. the other?
Perhaps this will help more:
http://www.xilinx.com/bvdocs/appnotes/xapp259.pdf
From what I've seen in the past, it is quite rare to need
DESKEW_ADJUST, and in fact, FIXED or VARIABLE PHASE SHIFT usually
provides more flexibility if you need something along these lines.
Marc
Article: 63807
On Thu, 04 Dec 2003 22:44:53 +1100, Allan Herriman wrote:
> On Thu, 4 Dec 2003 02:30:30 -0800, "Eric BATUT" <grostuba@ifrance.com>
> wrote:
>
>> Is there actually something to gain from purchasing a second CPU
>> (since the machine itself is bi-processorable) ?
>
> The Xilinx tools are single threaded, but having two processors allows
> you to run two instances of the Xilinx software at the same time.
>
> This can halve the number of machines you need in your server farm,
> which saves a lot of money, power and space.
>
> In my current job, we have three designers running routes on one dual
> processor server. This works quite well.
>
> In my last job, we had (before the redundancies) about 25 designers
> using about 10 machines in the server farm. Most of the servers could
> handle two jobs at once. The fastest machines usually had one or two
> jobs running; the slower ones were rarely used.
>
> (Note: you'll need to have some custom software to allocate jobs to
> servers. This is a lot easier if you don't use the Xilinx GUI.)
>
>
> None of this will make much sense if you are a "one-person shop" with
> only a single computer.
>
> Regards,
> Allan.
Use Linux and you can take advantage of the second processor as well as
processors on other Linux systems. The -m switch to par allows you to do a
multi task run
-m = Multi task par run. File <node list file> ",
contains a list of node names on which to run the jobs. (This
option is not currently supported on WIN NT/WIN 95 systems).
Article: 63808In article <ee81679.-1@WebX.sUN8CHnE>, Eric BATUT <grostuba@ifrance.com> wrote: >Is there actually something to gain from purchasing a second CPU (since >the machine itself is bi-processorable) ? Even if there is no gain from the toolflow time, there is often a huge gain from a user-time, as now you can do ssh/email/web surfing while your jobs are running. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 63809
I'm trying to create DDR SRAM data I/O pads and am having problems
"pushing" the tri-state enable flip-flop into the IOB. I get the
DDR in/out DATA flip-flops packed into the IOB correctly, but XST 5.2
refuses to use the IOB's tri-state enable flip-flop. This is
targeted at a V2-Pro part.
I'm "hand" instantiating the output DATA ddr "flops", but, for
a variety of reasons, I REALLY don't want to hand instantiate
components to control the tri-state, I'd really like to infer them.
In this design the tri-state control signals are not really "ddr",
they only need to change on posedge clock.
Here's a snippet of my code:
// instantiate 72 DDR output cells
FDDRRSE u0ddr_q (
.C0 (clk_outn), .C1 (clk_out),
.R (1'b0), .S (1'b0), .CE (1'b1),
.D0 (sr_dout[0]), .D1 (sr_dout[72]), .Q (sr_q[0])
);
FDDRRSE u1ddr_q (
.C0 (clk_outn), .C1 (clk_out),
.R (1'b0), .S (1'b0), .CE (1'b1),
.D0 (sr_dout[1]), .D1 (sr_dout[73]), .Q (sr_q[1])
);
FDDRRSE u2ddr_q (
.C0 (clk_outn), .C1 (clk_out),
.R (1'b0), .S (1'b0), .CE (1'b1),
.D0 (sr_dout[2]), .D1 (sr_dout[74]), .Q (sr_q[2])
);
......
// infer the tri-state output control
// try to get the control bit 'pushed' into the IOB tri-state control f/f
reg sr_oe;
// synthesis attribute IOB of sr_oe "TRUE"
always @(posedge clk_outn)
sr_oe <= bar;
assign sram_dq[71:0] = (sr_oe) ? 72'bz : sr_q[71:0];
a) I have tried a BUNCH of variations on this scheme with no luck.
1) force sr_oe to be a 72 bit vector
2) add KEEP attributes
3) remove the IOB attribute
4) change the tri-state assign statement to be 72 individual
statements, one for each bit.
b) I have set the synthesis options to use IOB flip-flops.
I suspect the Xilinx tools don't like the combination of instantiated
DDR data output flops and inferred tri-state registers pushed into the
IOB.
Any ideas?
John P
Article: 63810Tobias, here are the basics: •Din is always an input, but it has meaning only for a write cycle; the read cycle just ignores the data on Din. •Dout is always active (there is no 3-state) as either a read output, or representing the data being written ( or in V2/S3 optionally the old data or the previous data...) Interconnecting Din and Dout seems to be meaningless to me. (Microprocessors and some memories use bidirectional data bussing mainly to reduces the pin-count. That consideration does not apply to the same extent inside an FPGA.) Peter Alfke ============== Tobias Möglich wrote: > > Hello, > > Still a question. > It seems, that it is not possible to configure the FPGA in the way > shown below. > Is it right: A Xilinx Spartan-IIE (and Virtex, Spartan 3 ,...) has: > > a DIN for port_A with own pins > a DOUT for port_A with own different pins > a DIN for port-B with own pins > a DOUT for port_B with own different pins. > > > > Port > A Port B > [Image] > > > Isn't it possible to use one Databus for port_A (for IN and OUT) and > one Databus for port_B (for IN and OUT). > Do I really have to use extra pins for DIN port_A and DOUT port_A? > Isn't it possible to use the same data pins for In and Output as in > the Figure above? > > > Tobias. > > > > > >Article: 63811
"Jake Janovetz" <jakespambox@yahoo.com> wrote in message news:d6ad3144.0312030941.60ffcc97@posting.google.com... > What do you folks use as a command line shell in Windows? I know > several people are working outside of Project Navigator (Xilinx) for > builds and it Windows is just not a very comforting environment for > shell folks. What 'make' utility do you use? > For Window$ Explorer sustitution: Windows Commander (can't live without it) Cheers KlausArticle: 63812
Hi, You can find some answers to your questions here: http://www.engr.sjsu.edu/~crabill/lab5.pdf Eric Fred H wrote: > > I'm pretty new to FPGA-programming, and I've yet to understand > quite of the steps I go through from compiling my vhdl-files, > to finally generating bit-files. > > I'm working with a Xilinx II Pro FPGA, using ISE 6.1i, and I'm > only starting to get familiar with the tools. But I'm having > some problems understanding what all the (automated) steps do, > and what they actually mean. > > What I want to know, is the following: > > 1. What does the "Translate" step do? What is actually produced > by this step in the implementation ladder? > 2. What happens in the "Map" stage, and what is produced? > 3. What is left for "Place & Route" to do? (A whole lot I > suppose, since it takes so long...) > > Well, you get the picture. I'm a genuine newbie, and I want to > know what the he... is going on when I skillfully double click > the "Implement Design" icon :p > > Any commens, or links to introductory guides will be greatly > appreaciated. And I might as well warn you right away. I will > probably bother you guys with questions about whe myriad of > different files produced during the "implement design" process > when I'm starting to undersand what is actually happening during > that process. > > Sincerely > -Fred, Norway.Article: 63813
> Even if there is no gain from the toolflow time, there is often a huge > gain from a user-time, as now you can do ssh/email/web surfing while > your jobs are running. > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu I agree. Throw in a GeForce FX 5800 card, and it'll be truely an Ideal machine :_)Article: 63814
Pierre-Olivier wrote: >> Inside the FPGA, don't use vendor core generators. >> Write your own code that infers what you need. > > Mike, I'd be interested in hearing why you think this, I'm not sure that > I agree. This is a trade-off of device utilization verses independence and ease of simulation. There will always be things you can't infer from code. I'm happy to leave those things unwired. -- Mike TreselerArticle: 63815
"Tobias Möglich" <Tobias.Moeglich@gmx.net> schreef in bericht news:3FCB5117.960F18AA@gmx.net... > Hello! > > Thank you for your advice. Yes, I tried it the CoreGenerator. > Hm. One more question: > Do I have to copy the source code generated by the CoreGenerator in a > vhd-file or > is it enough to add the generated core (-> including the xco-file by saying: > "New Source... IP(CoreGen & Architecture Wizard) in Xilinx ISE Foundation)? > > Tobias > > > > The source code generated by the core generator is only needed for simulation. You can just add the generated core to your project and create an instance in the right HDL file or schematic MarkArticle: 63816
Vinh Pham <a@a.a> wrote in message news:ENLzb.15714$Kf2.4996@twister.socal.rr.com... > > Even if there is no gain from the toolflow time, there is often a huge > > gain from a user-time, as now you can do ssh/email/web surfing while > > your jobs are running. > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.edu > > I agree. Throw in a GeForce FX 5800 card, and it'll be truely an Ideal > machine :_) I'd rather have my Matrox dual head card with two big monitors, I recon it makes me a fair bit more productive. Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 63817
xilkernel maintains an internal table of ready/waiting/running processes and their priorities. This table can be statically initialized by specifying a list of process start-addresses and priorities in the MSS (assign to the PROCESS_TABLE parameter). On startup xilkernel starts running the highest priority process in this table. In your example, the process table is initialized with a single element with priority 1 and start address 0xA0000000 so xilkernel will start executing the code at this address. If you want two threads, this main application can start up the other other thread/process using the create_process() or create_thread() function, or you can write the other thread as a separate application with a different start address, and specify that on the PROCESS_TABLE list in the MSS file. -- Mohan Frank wrote: Hi, Could anyone explain the meaning of the process_table parameter in the mss file (when using the xilkernel). I have a bootloader with the following stuff in the mss file: BEGIN LIBRARY PARAMETER LIBRARY_NAME = xilkernel PARAMETER LIBRARY_VER = 1.00.a PARAMETER MAX_PROCS = 1 PARAMETER PROCESS_TABLE = ((0xA0000000, 1)) PARAMETER CONFIG_THREAD_SUPPORT = true PARAMETER MAX_THREADS = 2 PARAMETER THREAD_STACK_SIZE = 0x100 PARAMETER CONFIG_SEMA = true PARAMETER MAX_SEMA = 1 END Besides that, I have an application (with his own makefile) which should be run from address 0xA0000000, so in the makefile I use the linker option LFLAGS = -xl-mode-xilkernel -Wl,-defsym -Wl,_TEXT_START_ADDR=0xA0000000 When I disassemble the .elf file of the application, it's all ok (addresses starts from 0xA0000000). So what is the meaning of the address in the process_table parameter in the mss file of the bootloader?? Does it make any sense? Or do I not need the process stuff at all, but just use the thread parameters (I only want an application which contains two threads)?! Thanks, FrankArticle: 63818
The CPU will write bytes into a register, at 8M-bytes/second... The FPGA will read that register and do some signal processing (Shifting, addition, etc) on it. Can FPGA use the same clock with the CPU? CPU is a ARM7...FPGA is Spartan-2, 250K... Vinh Pham <a@a.a> wrote in message news:xHCzb.3169$WT6.719@twister.socal.rr.com... > Heya Kelvin, > > > I want to know how to properly interface between the CPU clock and the > FPGA > > clock. > > That's a pretty broad question. There are all sorts of solutions that vary > in complexity. It will help if you can explain your design situation in > more detail. What sort of data is flowing between the two clock domains? > What's the interaction like? > > Regards, > Vinh > >Article: 63819
On Thu, 04 Dec 2003 11:11:25 -0500, "B. Joshua Rosen" <bjrosen@polybus.com> wrote: >On Thu, 04 Dec 2003 22:44:53 +1100, Allan Herriman wrote: >Use Linux and you can take advantage of the second processor as well as >processors on other Linux systems. The -m switch to par allows you to do a >multi task run > > -m = Multi task par run. File <node list file> ", > contains a list of node names on which to run the jobs. (This > option is not currently supported on WIN NT/WIN 95 systems). > That only applies if you are using the -n switch (to try multiple cost tables) as well. If that's what you want to do, then good. My experience has been that most par runs are done with -n 1, and -m will give no speedup whatsoever in this case. Regards, Allan.Article: 63820
Hi, I recently started working with FPGAs and am would like to learn about floorplanning techniques. Could someone point me to documents or design guides dealing with what issues should be kept in mind while floorplanning a complex design.. Thanks to all who reply!! R.B.Article: 63821
"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes: > You bright up a good subject, and you're absolutely correct that if you > continuously send data from one serial port at 9600.01bps to a receiver at > 9600, sooner or later there must be a buffer overflow. No, that will work just fine. When a real UART is set for one stop bit, it actually only needs just over 1/2 a stop bit (usually 9/16). > There's no way around this Certainly there are ways around it. Read ITU Rec. V.14. > Nothing wrong with 16x oversampling (it will definitely help -- a little), It helps a lot, if you do it right.Article: 63822
"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes: > Unless your (slightly slower) transmitter also has the capability of > producing shortened start (or stop) bits, An async transmitter should NEVER produce shortened start or stop bits! It is the RECEIVER that should handle short stop bits, in order to deal with the exact sort of speed mismatch you're talking about. > how those this approach 'fix' the > problem? If the date rates are, say, 9601 received BPS and 9600 transmitted > BPS, detecting early start bits just buys you one extra bit interval before > your overrun your buffers, doesn't it? No, if the receiver works correctly this should be maintainable indefinitely (provided there's nothing else in the receiving device that overflows).Article: 63823
"juergen sauermann" <juergen.sauermann@t-online.de> writes: > Valentin, apparently you are trying to resolve the clock difference by cutting the stop bit in order to achieve a higher transmission rate. > > That is a very nice idea and it is completely wrong. If it's completely wrong, why did the ITU standardize it in the V.14 standard? Admittedly shaving stop bits should only be used in certain limited circumstances. It is not intended to deal with sending data to a receiver that is running slightly slower than the transmitter. Rather, it is used when converting slightly overspeed data from a synchronous modem modulation to async (when no error control protocol like V.42 is in use). Only a small number of commercially produced UARTs, such as the NEC uPD7201, fail to work correctly with slightly short stop bits. This problem was commonly seen on the AT&T 7300 Unix PC in the late 1980s.Article: 63824
"Jim Granville" <no.spam@designtools.co.nz> writes: > UARTs look for the START edge, from the _middle_ of the STOP bit. > With x16 clocking, typically that gives 8 possible time slots for earlier > start. Actually they usually start looking for a start transition 9/16 of the way into the previous stop bit. Some UARTs with noise detection sample the RX input at 7/16, 8/16, and 9/16 of the bit time, so those might not start looking for a start bit until 10/16 of the way into the previous stop bit. > I would agree that a half-bit jump in STOP, as the OP first suggested, > is NOT a good idea, but fractional (1/16 quantized ) STOP changes are > valid and safe. Yes, with rare exceptions such as the NEC uPD7201, which actually requires a full stop bit on receive.
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