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
Jecel wrote: > If you are going to compile Forth then CALL is probably the first > instruction you want to optimize and I didn't even see it or an > equivalent in your list. You are right. My idea was to use something like "pushr byte 3 +PC", "load PC word :my_function" for the call and "popr PC" for the return. But as Jim noticed, there is some room in the branch commands and "jump" is redundant, because it can be implemented with "loadpc word :label" (and even relative to PC with "loadpc word :label +PC", or for skipping the next instruction, the one byte instruction "loadpc # 1 +PC" is possible), so it could be added to the branch commands. But to make the pop/load commands more complete, I've added it as a special destination case and reorganized the branch commands, which now can branch on 8 conditions. I've updated the documentation at http://www.frank-buss.de/vhdl/forth-cpu.html > Other than that this is probably a very > reasonable way to encode Forth. Given that you have spare bits in > several cases my guess would be that it isn't an optimal encoding > (Chuck Moore's 5 bit instruction set and the variations people have > made are probably closer to optimal). It could be encoded more compact, but my idea was to avoid large demultiplexers for decoding every single command. Maybe I should start implementing the design to see if this works :-) > When you have an address register like in the MISC processors it is a > good idea to avoid reloading it when possible. In this case having both > 6+i accesses happen next to each other does that. And in general it > isn't very good to allow the stack to get very deep with temporary > values when programming stack machines. Thanks. Looks like most of the time an arithmetic operation is executed before "pop A", so I've used one bit for all instructions, which specifies that a "pop A" is executed after the command to compress the code even more: push byte 5 ; i=5 :loop dup popa ; i @A byte ; (i) i over ; i (i) i push byte 6 ; 6 i (i) i add popa ; (i) i @A byte ; (6+i) (i) i over ; (i) (6+i) i !A byte ; (6+i) i over popa ; (6+i) i !A byte ; i dec ; i-1 bcc byte :loop drop ; empty stack Now it is 16 bytes long, just 1 byte more than the shortest code so far, the 6502 code (it needed 15 bytes, not 13 as I wrote). > By the way - this code fragment that you have been testing various > architectures with has a problem in that in general the first word to > be swapped would be some random one and not happen to be address zero. This was by intention to see if there are some tricks for zero based addressing. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 107951
Brad Eckert wrote: > Since you have flag registers, you need a way to push and pop them if > you have interrupts. You can use "pop S" and "push S" or even "popr S" and "pushr S" with my instruction set. > CALL is used in Forth much more often than in other languages so you > should try to encode it compactly. Yes, I've added it as a possible destination to the "pop" command. > 8-bit opcodes are kind of nice because serial flash is pretty fast. In > a Spartan3, you could map the lower 2K bytes of program space to a BRAM > block and the rest to external flash. You keep the fast (mostly kernel) > words in the BRAM. Thanks, mapping the flash into the address space is a good idea and maybe 2 BRAMs: one for the TCP/IP stack and one for fast programs and other data. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 107952
Frank Buss wrote: > and reorganized the > branch commands, which now can branch on 8 conditions. There was one bit too much, so there are 4 conditions only. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 107953
I bought a Spartan-3 kit about a year ago and it came with V7.1i of the software, I'm wondering what the kits are shipping with now? On a related subject I bought a copy of MatLab for use with the Xilinx software in creating DSP functions. I bought R14 which is compatible with the software I now have, but they ran out of the old copies and gave me a copy of the 2006a release instead, anyone have a clue if that will work also? -- Cecil KD5NWA www.qrpradio.com www.hpsdr.com "Sacred Cows make the best Hamburger!" Don Seglio BatunaArticle: 107954
Frank Buss wrote: > Jecel wrote: >>Other than that this is probably a very >>reasonable way to encode Forth. Given that you have spare bits in >>several cases my guess would be that it isn't an optimal encoding >>(Chuck Moore's 5 bit instruction set and the variations people have >>made are probably closer to optimal). > > > It could be encoded more compact, but my idea was to avoid large > demultiplexers for decoding every single command. Maybe I should start > implementing the design to see if this works :-) Yes, but unless you have large amounts of 5 bit memory lying about :) there is more point in focusing on packing the 8 bit opcodes, to try and reduce the use of 16 bit ones. If you do plan to use serial flash, the keep in mind the (IIRC) 5 byte address reload time, so short (1 byte) skips up to 5 bytes ahead would be efficent. In a FPGA, another useful thing to cache could be constants ? - so you do not have to reload the Serial address pointer, just to access (smaller) constants. -jgArticle: 107955
Brad Eckert wrote: > Jim Granville wrote: > > > > Looks good - some brief comments : > > I think the opcode is 8 bits ? > > That's good for off-chip memories. > > You could optionally allow a 9-bit opcode, for where the memory is FPGA > > BRAM ? That could also allow an option for 32 bit registers ? > > > Since you have flag registers, you need a way to push and pop them if > you have interrupts. Usually Forth chips use 0=, 0< and IF or IF and > -IF instead of flag registers, so there is nothing to save. This means > that signed comparisons like < take longer but that doesn't seem to be > a problem. I got around that in my Forth CPU by pushing the return address on the return stack and the PSW on the data stack at the same time, so there was no speed penalty. It did require a separate return from interrupt instruction as compared to the standard return. Although the 9 bit wide block ram is pretty much a standard feature on FPGAs, I did not take advantage of it for the instruction word. I wanted to keep the instruction size minmal so that decoding would take less logic. I could have gone with a 5 bit opcode, but I decided to take advantage of the extra bits and encode a variable sized literal field for LIT, CALL and JUMP instructions. This should significantly reduce the code size for small programs.Article: 107956
In message <1157237173.937461.171550@p79g2000cwp.googlegroups.com>, dated Sat, 2 Sep 2006, "dougfgd@gmail.com" <dougfgd@gmail.com> writes >deterioration of performance both with age and boredome A boredome is indeed an elderly person, trichologically challenged, with an agenda to share with anyone who can't escape. -- OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk 2006 is YMMVI- Your mileage may vary immensely. John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UKArticle: 107957
I would like to exchange information on the Xilinx VSK with others
using the kit.
In particular I have the following observations:
A1. The VSK provides no help to people who do not wish to invest in (a)
Matlab, (b) Simulink, (c) ISE 8.1, and (d) an MXE version compatible
with 8.1. VSK assumes that anyone buying VSK will also buy these
packages, or has them already.
A2. Xilinx should state the conditions in A1 clearly where it offers
VSK for sale.
A3. There is one other serious flaw in the VSK and in the VIOBUS in
that they do not allow for the video clock in the VIODC to be passed
down to ML402 --- so far as I understand the documentation. Only the
100 MHz ML402 clock can be passed up to the VIODC. This situation is
not conducive for testing video designs.
A4. Ideally, Xilinx should have sold the VSK with the following
A4.1. Verilog and VHDL code for the VIODC (Video I/O Daughter Card)
to perform the setup for the video encoder and decoder chips.
A4.2. Provision for passing the pixel clock from VIODC to ML402.
A4.3. Some minimal Verilog and VHDL code for the ML402 including a
pass-through module. A user could then replace the pass-through module
with his/her code in a few minutes and have had a fully functional test
system.
As things stand, I think the VSK is quite useless for my purposes.
I am eager to hear from other users.
Arun Kumar
Article: 107958Dave schrieb: > I've got a ML403 Virtex 4 development board with an FX12 part on it. I've > developed several VHDL components that I need to interface to an embedded > MicroBlaze. The VHDL components interface to the outside world through FPGA > pins. I've looked at some Xilinx examples of devices like LEDs and switches > interfacing to the MicroBlaze but these devices are always defined during > the Base System Builder in XPS. I've tried the process of adding a GPIO for > 32-bit input as: > > 1. Add IP for GPIO > 2. Attach the GPIO to the OPB > 3. Set the port connection IP2INTC_Irpt to opb_gpio_IP2INTC_Irpt > 4. Set GPIO_in to opb_gpio_0_in > 5. Generate addresses > > Do the GPIO pins have to be mapped to FPGA I/O pins? I had to select "Make > External" on each connection or I got errors when trying to build the > project. > > How do I attach local component functionality (known only to the top-level > VHDL) to these GPIO pins? > > Are there any __simple__ examples of GPIO usage and instantiation with > connections to the top-level architecture? > > Any help would be very much appreciated. > > Thanks. > > Dave Dave, first of all, it makes sometimes sense to learn by doing and trying. sure you get mistakes and have to retry but you learn for good. the _IN ports are used only if the GPIO is not configured as bidir read the datasheet ! if you want to use the pins as external you sure nead to make them external and the you also need to add the LOC constraints into the UCF file. as soon as that is done you can access the GPIO_in as inputs by simply reading the GPIO base address regarding you question about the toplevel entity, I dont understand what you are talking about. if you work in XPS then its all there for you and there is nothing to worry about, you do as explained above and you get an functional SoC design that works. if you want to use the EDK system as module as 'submodule' in ISE as toplevel then that is another topic. but for starters I suggest you work a little while with XPS only. Antti http://xilant.comArticle: 107959
dakkumar schrieb: > I would like to exchange information on the Xilinx VSK with others > using the kit. > > In particular I have the following observations: > > A1. The VSK provides no help to people who do not wish to invest in (a) > > Matlab, (b) Simulink, (c) ISE 8.1, and (d) an MXE version compatible > with 8.1. VSK assumes that anyone buying VSK will also buy these > packages, or has them already. > > A2. Xilinx should state the conditions in A1 clearly where it offers > VSK for sale. > > A3. There is one other serious flaw in the VSK and in the VIOBUS in > that they do not allow for the video clock in the VIODC to be passed > down to ML402 --- so far as I understand the documentation. Only the > 100 MHz ML402 clock can be passed up to the VIODC. This situation is > not conducive for testing video designs. > > A4. Ideally, Xilinx should have sold the VSK with the following > > A4.1. Verilog and VHDL code for the VIODC (Video I/O Daughter Card) > > to perform the setup for the video encoder and decoder chips. > > A4.2. Provision for passing the pixel clock from VIODC to ML402. > > A4.3. Some minimal Verilog and VHDL code for the ML402 including a > pass-through module. A user could then replace the pass-through module > with his/her code in a few minutes and have had a fully functional test > > system. > > As things stand, I think the VSK is quite useless for my purposes. > > I am eager to hear from other users. > > Arun Kumar as much as I have understood much of the Xilinx "Video" stuff is only useable for those who make 20kUSD+ upfront investments to buy bunch of 3rd party stuff! :( so whatever you want todo you are at your own and have todo almost everything from scratch. AnttiArticle: 107960
On 2 Sep 2006 08:32:07 -0700, zwsdotcom@gmail.com wrote:
>
>Brian Drummond wrote:
>
>> You can either get creative about finding or guessing the actual
>> download URL
...
>wget --user={username} --password={password}
>http://www.xilinx.com/webpack/index.htm
>
>then poke in the HTML file to get the direct download links (you can't
>really read the HTML file easily without the CSS). And here they are:
Creative enough! I usually resort to "view/page source" for the same
purpose.
Now all you have to do is hope both ends stay up for a 970MB download.
(I pity anyone still in 56k-land who needs WebPack. I needed WebPack
6.1 before ADSL got here, and 240MB was quite bad enough...)
- Brian
Article: 107961Brian Drummond wrote: > Now all you have to do is hope both ends stay up for a 970MB download. > > (I pity anyone still in 56k-land who needs WebPack. I needed WebPack > 6.1 before ADSL got here, and 240MB was quite bad enough...) It didn't work most of the time in one download step when I tried it (sometime only a few MB were missing), even with 2 Mbit DSL, like I have. A download manager like LeechGet solved it. Maybe Xilinx should buy something like this tool for their distribution, or setup a Torrent link. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de From spampostmaster@comcast.net Sun Sep 03 05:00:08 2006 Path: newssvr14.news.prodigy.com!newsdbm05.news.prodigy.com!newsdbm04.news.prodigy.com!newsswing.news.prodigy.com!prodigy.com!newscon06.news.prodigy.com!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 03 Sep 2006 07:00:08 -0500 From: Phil Hays <spampostmaster@comcast.net> Subject: Re: Impossible to download WebPACK? Date: Sun, 03 Sep 2006 05:00:08 -0700 User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2006.09.03.12.00.08.49154@comcast.net> Newsgroups: comp.arch.fpga References: <1157138233.084461.187630@m73g2000cwd.googlegroups.com> <44f9ffd6$1@clear.net.nz> <1157248277.345247.130340@h48g2000cwc.googlegroups.com> <1157251050.800274.72150@74g2000cwt.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 12 NNTP-Posting-Host: 24.16.63.21 X-Trace: sv3-ziTGBERpCNpNhSUNtRgepuetx/wockBjOK/e6FqvXUUsVLXFpd2KNvUij5VDQYorQ6hejS1acty7OSl!z86ek1rAyaTe8RsrKqDmJFJBD2rrzwAaDZRXHB98661b1ynGLmW0lQW1OHMqIh1DwL7wINmAcX/+!5/8P X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: prodigy.net comp.arch.fpga:118845 Alan Nishioka wrote: > As a data point, webpack just downloaded fine for me. As a data point, webpack downloaded just fine for me as well. I'm near Seattle WA, using firefox 1.5.0.4 on Fedora Core 5 (Linux), Comcast network connection. Time was under an hour. -- Phil Hays (Xilinx, but speaking for myself)Article: 107962
Hi Given a design placeed and routed in FPGA, I need to know "how much wiring resources my implementation are using out of total wiring resources". I am using Xilinx Virtex-II Pro. In PAR report, logic (slice, LUT, FF,...) resource utilization (in percentage) is available. But, wiring (wire, switch box) resource utilization (in percentage) is not available. Question is that 1. How can we know wiring resource utilization? 2. Can "number of used switch box" out of "total number of switch box" be a metric of wiring resource utilization? If yes, are there any method to know that? Thankyou for remark, suggestion.Article: 107963
The second one is incorrect because it does not be explicitly reset and you are getting 'lucky' in the behavioural sim because the simulator is initializing the value of count to 0 for you whereas in 'the real world' you generally don't get this behaviour (unless the device explicitly guarantees you some 'powerup default' value. Had you used 'unsigned (3 downto 0) instead of 'integer' for the signal count, the initial value assigned by the simulator would be 'U' (undefined) and it might have been clearer about why the reset is necessary. Having said that though, I am at a bit of a loss to explain why the post-synthesis sim got the initial value of '0000' correct (I would've expected it to be 'UUUU' but in any case you do need a reset. Another oddity is the counting by 2 and init to 0 which implies that the counter will never reach a value of that will cause it to get reset to 0 properly in your behavioural sim....did you test this? When the count tries to go from 14 to 16 you should get a fatal sim error because count goes out of it's defined range of 0 to 15. Although integer and their subtypes are in many cases a more 'natural' expression of what you're trying to accomplish, you do have to be a bit more diligent about making sure that things that get feedback (like counters) get explicitly reset or you'll run into cases exactly like this where the pre-route simulation works but does not match post-route. Until you master this, you might consider using the 'numeric_std' package to do your arithmetic operations. With that package, when you don't explicitly reset things they will be undefined (i.e. 'U') and it will be easier to see that you got the design correct. KJArticle: 107964
Michael A. Terrell wrote: > I worked seven months of 112 hours per week, and got paid for 148 > hours (16 hours/day with time and a half for anything over 40 hours) > except for Christmas Day and New Years Day when I got paid an extra 16 > hours per day. On top of that, my boss was bitching that I should be > willing to work even more hours. The hours do not matter. All that matters is what did you actually worked out for yourself. As far as the problem goes, if you can't work it with your head, don't try to work it with your arse. > > On top of that, my boss was bitching that I should be > willing to work even more hours. Who should be happier, you or your boss? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.comArticle: 107965
In message <OwDKg.20560$kO3.16802@newssvr12.news.prodigy.com>, dated
Sun, 3 Sep 2006, Vladimir Vassilevsky <antispam_bogus@hotmail.com>
writes
>Who should be happier, you or your boss?
Most of the time, you. At raise time, the boss. (;-)
Notice how well I can speak Merkan ('raise')!
--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
2006 is YMMVI- Your mileage may vary immensely.
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
Article: 107966"Antti" <Antti.Lukats@xilant.com> wrote in message news:1157277138.918019.21750@p79g2000cwp.googlegroups.com... > Dave schrieb: > >> I've got a ML403 Virtex 4 development board with an FX12 part on it. >> I've >> developed several VHDL components that I need to interface to an embedded >> MicroBlaze. The VHDL components interface to the outside world through >> FPGA >> pins. I've looked at some Xilinx examples of devices like LEDs and >> switches >> interfacing to the MicroBlaze but these devices are always defined during >> the Base System Builder in XPS. I've tried the process of adding a GPIO >> for >> 32-bit input as: >> >> 1. Add IP for GPIO >> 2. Attach the GPIO to the OPB >> 3. Set the port connection IP2INTC_Irpt to opb_gpio_IP2INTC_Irpt >> 4. Set GPIO_in to opb_gpio_0_in >> 5. Generate addresses >> >> Do the GPIO pins have to be mapped to FPGA I/O pins? I had to select >> "Make >> External" on each connection or I got errors when trying to build the >> project. >> >> How do I attach local component functionality (known only to the >> top-level >> VHDL) to these GPIO pins? >> >> Are there any __simple__ examples of GPIO usage and instantiation with >> connections to the top-level architecture? >> >> Any help would be very much appreciated. >> >> Thanks. >> >> Dave > > Dave, > > first of all, it makes sometimes sense to learn by doing and trying. > sure you get mistakes and have to retry but you learn for good. > > the _IN ports are used only if the GPIO is not configured as bidir read > the datasheet ! > > if you want to use the pins as external you sure nead to make them > external and the you also need to add the LOC constraints into the UCF > file. > > as soon as that is done you can access the GPIO_in as inputs by simply > reading the GPIO base address > > regarding you question about the toplevel entity, I dont understand > what you are talking about. if you work in XPS then its all there for > you and there is nothing to worry about, you do as explained above and > you get an functional SoC design that works. > > if you want to use the EDK system as module as 'submodule' in ISE as > toplevel then that is another topic. but for starters I suggest you > work a little while with XPS only. > > Antti > http://xilant.com > Hi Antti - Thanks for taking the time to respond. I agree entirely that it's usually good to use trial-and-error as a training aid. But it only works if you eventually start making some repeatable progress, which has not been my case. I've been trying for a couple of weeks and have not made any progress. The GPIO-related documentation included in the XPS does not address how to map the GPIO to another component included in the design. My project includes several VHDL components which have been included on a top-level ISE project. These components serve as the interface to the outside world to and from the FPGA. Some of these components are inherited from other projects. They do some manipulation and conditioning on the inputs from the outside world before making them available to the MicroBlaze. The MicroBlaze component is included as a subcomponent of the top-level system. Its purpose is to process conditioned inputs, store them in some local registers, and send an output to a component which further conditions the data then outputs it to the outside world. It was thought to use GPIO interfaces to the MicroBlaze and other VHDL components. (I apologize if I'm not using the correct terminology) I cannot simply write data to or read data from a GPIO port from the MicroBlaze. The inputs and outputs go through conditioners. Since I have to go through conditoners and the GPIO does not need to talk directly to the outside world, my question is can I map the GPIO_IN port pins to the conditoner output port pins without having to use actual FPGA pins? A simple example of what I'm talking about would be a MicroBlaze system with a 32-bit GPIO output port writing bits 0 and 1. A component defined in the ISE top-level VHDL has a logic function of "anding" the 0 and 1 bits from the GPIO and generating a single output to the FPGA pin interfacing to the real world. In this case, there is no need for the GPIO pins to be mapped to the FPGA I/O pins. Is this possible? Is there a simple example of something like this being done? Is there a better way of doing this? Thanks again. DaveArticle: 107967
Vladimir Vassilevsky wrote: > > Michael A. Terrell wrote: > > > I worked seven months of 112 hours per week, and got paid for 148 > > hours (16 hours/day with time and a half for anything over 40 hours) > > except for Christmas Day and New Years Day when I got paid an extra 16 > > hours per day. On top of that, my boss was bitching that I should be > > willing to work even more hours. > > The hours do not matter. All that matters is what did you actually > worked out for yourself. As far as the problem goes, if you can't work > it with your head, don't try to work it with your arse. I got stuck working the overtime because the idiot ordered the wrong piece of equipment for a CATV headend. he insisted that Jerrold, (General Instruments) didn't know what they were talking about, and that our 10,000 cable converters were already tuned to the channel he ordered. They weren't, and the jackass refused to change the order, so I had to modify 10,000 pieces of equipment instead. > > > > > On top of that, my boss was bitching that I should be > > willing to work even more hours. > > Who should be happier, you or your boss? Ernie wasn't very happy by the time it was over, then was forced to quit or be fired a few months later at a time when my word could have let him keep his job. On top of that, I got ten times what he did for my Christmas bonus that year. I made almost twice what he got that year, then he was looking for another job with the company telling his prospective new employers that they couldn't comment till the lawsuit was settled. :) > Vladimir Vassilevsky > > DSP and Mixed Signal Design Consultant > > http://www.abvolt.com -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 107968
Yifei Luo wrote: > I am a newer of System Generator. I designed an FIR with system > generator, only using the Delay, Cmult, Addsub, upsampler, downsampler > and Gateway In/Out block. Then I made it into a subsystem and masked it. > > Question are : > Do I need to set the filter coefficient? > What does filter coefficient stands for? > And what value should I give to the coefficient? > > Thank you very much for your kindly help! Yes, you need the filter coefficients. They determine the frequency response of the filter (the coefficients are the impulse response for an FIR filter). You will need to use a filter design program to generate your filter coefficients. Design programs generally use the Parks-McClellan algorithm. Matlab's signal processing or filter design tool boxes have it. There is also a relatively cheap ($100) FIR filter design program called ScopeFir that does it (www.iowegian.com) that I use and am quite happy with. There are a number of other filter programs as well.Article: 107969
John Woodgate wrote:
>
> In message <OwDKg.20560$kO3.16802@newssvr12.news.prodigy.com>, dated
> Sun, 3 Sep 2006, Vladimir Vassilevsky <antispam_bogus@hotmail.com>
> writes
>
> >Who should be happier, you or your boss?
>
> Most of the time, you. At raise time, the boss. (;-)
>
> Notice how well I can speak Merkan ('raise')!
His last name was Bliss, and well, you know what they say! ;-)
--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.
Michael A. Terrell
Central Florida
Article: 107970dakkumar wrote: > I would like to exchange information on the Xilinx VSK with others > using the kit. > > In particular I have the following observations: > > A1. The VSK provides no help to people who do not wish to invest in (a) > > Matlab, (b) Simulink, (c) ISE 8.1, and (d) an MXE version compatible > with 8.1. VSK assumes that anyone buying VSK will also buy these > packages, or has them already. > > A2. Xilinx should state the conditions in A1 clearly where it offers > VSK for sale. > > A3. There is one other serious flaw in the VSK and in the VIOBUS in > that they do not allow for the video clock in the VIODC to be passed > down to ML402 --- so far as I understand the documentation. Only the > 100 MHz ML402 clock can be passed up to the VIODC. This situation is > not conducive for testing video designs. > > A4. Ideally, Xilinx should have sold the VSK with the following > > A4.1. Verilog and VHDL code for the VIODC (Video I/O Daughter Card) > > to perform the setup for the video encoder and decoder chips. > > A4.2. Provision for passing the pixel clock from VIODC to ML402. > > A4.3. Some minimal Verilog and VHDL code for the ML402 including a > pass-through module. A user could then replace the pass-through module > with his/her code in a few minutes and have had a fully functional test > > system. > > As things stand, I think the VSK is quite useless for my purposes. > > I am eager to hear from other users. > > Arun Kumar > Xilinx has targeted the kit toward the easiest development path, which for someone not already familiar with DSP design is without a doubt to use system generator, which requires matlab and simulink. However, although those are recommended by Xilinx, they are NOT required to do a video design. Where Matlab and Simulink are third party products, Xilinx can't really distribute them without compensation to Mathworks. Those are somewhat pricey products, and if you want a bundled package, I'm sure you could get it....at a cost commeasurate with the cost of included products. I agree that it would have been more useful with the skeleton designs done in VHDL or verilog and included with the package, however seeing some of the other reference designs, it would probably only be marginally functional, and probably wouldn't be suitable to your application without a more or less complete redesign anyway. It is a case of you get what you pay for.Article: 107971
Pasacco wrote: > Hi > > Given a design placeed and routed in FPGA, I need to know "how much > wiring resources my implementation are using out of total wiring > resources". > > I am using Xilinx Virtex-II Pro. > In PAR report, logic (slice, LUT, FF,...) resource utilization (in > percentage) is available. > But, wiring (wire, switch box) resource utilization (in percentage) is > not available. > > Question is that > 1. How can we know wiring resource utilization? > 2. Can "number of used switch box" out of "total number of switch box" > be a metric of wiring resource utilization? If yes, are there any > method to know that? > > Thankyou for remark, suggestion. > Why do you need to know the wiring resource utilization? The current crop of devices have ample wiring resources, and as long as it routes and meets timing, why does it matter how much is used? Designs use a very small percentage of the available routing resources. However, the high density of wiring is present in order to increase the likelihood of a route solution that meets timing. The actual routing resources used wil depend heavily on the place and route solution, which can change considerably with very small changes in the design. Because of these facts, the routing resource utilization has little value to the user of the devices.Article: 107972
"Ray Andraka" <ray@andraka.com> wrote in message news:COEKg.6772$SZ3.1348@dukeread04... > Yifei Luo wrote: > >> I am a newer of System Generator. I designed an FIR with system >> generator, only using the Delay, Cmult, Addsub, upsampler, downsampler >> and Gateway In/Out block. Then I made it into a subsystem and masked it. >> >> Question are : >> Do I need to set the filter coefficient? >> What does filter coefficient stands for? >> And what value should I give to the coefficient? >> >> Thank you very much for your kindly help! > > Yes, you need the filter coefficients. They determine the frequency > response of the filter (the coefficients are the impulse response for an > FIR filter). You will need to use a filter design program to generate > your filter coefficients. Design programs generally use the > Parks-McClellan algorithm. Matlab's signal processing or filter design > tool boxes have it. There is also a relatively cheap ($100) FIR filter > design program called ScopeFir that does it (www.iowegian.com) that I use > and am quite happy with. There are a number of other filter programs as > well. Check also www.digitalfilter.com This is freeware and is very good. It generates coeeficients, displays waveforms, etc. DaveArticle: 107973
<jjlindula@hotmail.com> wrote in message news:1156965525.874885.19940@m73g2000cwd.googlegroups.com... > Hello, I'm posting this question here because I want responses from > engineers, so please don't be offended. I want to know what your > thoughts are concerning Performance Appraisals at your company, are > they beneficial, how are they conducted, and what is the best way go > give performance appraisals? > > Where I work, the manager brings you into their office, starts a series > of short questions concerning your family and other things not relating > to your job and then finally gives you a pat on the back and says, good > job. Not much is really discussed and therefore not really useful. > > Your comments are welcomed. > > thanks, > joe > If I was a manager type bloke (like I dress up as a girly in my spare time) in charge of people (of various genders who can dress up how they like) I don't think I'd be doing performance appraisals..... Make of that what you will. DNAArticle: 107974
"Dave" <starfire151 AT cableone DOT net> schrieb im Newsbeitrag news:12fm5ti6ptenffc@corp.supernews.com... > > "Antti" <Antti.Lukats@xilant.com> wrote in message > news:1157277138.918019.21750@p79g2000cwp.googlegroups.com... >> Dave schrieb: >> >>> I've got a ML403 Virtex 4 development board with an FX12 part on it. >>> I've >>> developed several VHDL components that I need to interface to an >>> embedded >>> MicroBlaze. The VHDL components interface to the outside world through >>> FPGA >>> pins. I've looked at some Xilinx examples of devices like LEDs and >>> switches >>> interfacing to the MicroBlaze but these devices are always defined >>> during >>> the Base System Builder in XPS. I've tried the process of adding a GPIO >>> for >>> 32-bit input as: >>> >>> 1. Add IP for GPIO >>> 2. Attach the GPIO to the OPB >>> 3. Set the port connection IP2INTC_Irpt to opb_gpio_IP2INTC_Irpt >>> 4. Set GPIO_in to opb_gpio_0_in >>> 5. Generate addresses >>> >>> Do the GPIO pins have to be mapped to FPGA I/O pins? I had to select >>> "Make >>> External" on each connection or I got errors when trying to build the >>> project. >>> >>> How do I attach local component functionality (known only to the >>> top-level >>> VHDL) to these GPIO pins? >>> >>> Are there any __simple__ examples of GPIO usage and instantiation with >>> connections to the top-level architecture? >>> >>> Any help would be very much appreciated. >>> >>> Thanks. >>> >>> Dave >> >> Dave, >> >> first of all, it makes sometimes sense to learn by doing and trying. >> sure you get mistakes and have to retry but you learn for good. >> >> the _IN ports are used only if the GPIO is not configured as bidir read >> the datasheet ! >> >> if you want to use the pins as external you sure nead to make them >> external and the you also need to add the LOC constraints into the UCF >> file. >> >> as soon as that is done you can access the GPIO_in as inputs by simply >> reading the GPIO base address >> >> regarding you question about the toplevel entity, I dont understand >> what you are talking about. if you work in XPS then its all there for >> you and there is nothing to worry about, you do as explained above and >> you get an functional SoC design that works. >> >> if you want to use the EDK system as module as 'submodule' in ISE as >> toplevel then that is another topic. but for starters I suggest you >> work a little while with XPS only. >> >> Antti >> http://xilant.com >> > Hi Antti - > > Thanks for taking the time to respond. > > I agree entirely that it's usually good to use trial-and-error as a > training aid. But it only works if you eventually start making some > repeatable progress, which has not been my case. I've been trying for a > couple of weeks and have not made any progress. The GPIO-related > documentation included in the XPS does not address how to map the GPIO to > another component included in the design. > > My project includes several VHDL components which have been included on a > top-level ISE project. These components serve as the interface to the > outside world to and from the FPGA. Some of these components are > inherited from other projects. They do some manipulation and conditioning > on the inputs from the outside world before making them available to the > MicroBlaze. The MicroBlaze component is included as a subcomponent of the > top-level system. Its purpose is to process conditioned inputs, store > them in some local registers, and send an output to a component which > further conditions the data then outputs it to the outside world. It was > thought to use GPIO interfaces to the MicroBlaze and other VHDL > components. (I apologize if I'm not using the correct terminology) > > I cannot simply write data to or read data from a GPIO port from the > MicroBlaze. The inputs and outputs go through conditioners. Since I have > to go through conditoners and the GPIO does not need to talk directly to > the outside world, my question is can I map the GPIO_IN port pins to the > conditoner output port pins without having to use actual FPGA pins? > > A simple example of what I'm talking about would be a MicroBlaze system > with a 32-bit GPIO output port writing bits 0 and 1. A component defined > in the ISE top-level VHDL has a logic function of "anding" the 0 and 1 > bits from the GPIO and generating a single output to the FPGA pin > interfacing to the real world. In this case, there is no need for the > GPIO pins to be mapped to the FPGA I/O pins. Is this possible? Is there > a simple example of something like this being done? Is there a better way > of doing this? > > Thanks again. > > Dave > Dave, if you want to 'and' the outputs of the GPIO then you just use 'util_reduced_logic', connect the GPIO to the inputs and the single output as output pin to externa world. simple as that. if you want to some conditioner before the GPIO in then you can make a 'wrap' around the user logic, and after that wire the custom logic to gpio_in and the real inputs to your logic to the outside world. both of those are doable 100% in XPS without the need of the ISE toplevel. if you want to try just create a vhdl file with 1 vector input port and 1 vector output port import it into XPS and try to wire it between GPIO_in and external ports. if you want to use EDK system as ISE submodul, start new ISE project add dummy toplevel, then in ISE right click, new source, and select 'embedded processor' this will create EDK project as submodule in ISE. simple as that. Now if you want to wire some GPIO pins from the EDK into ISE toplevel and not to IOBs you may need to look into the EDK toplevel wrapper (usually system.vhd) you may need to remove the IOB prim instances there in order to connect them succesfully in the ISE toplevel. belive me, it all really 'just works' ! the only thing that may cause trouble are the extra io prims in the system.vhd - so you need either modify it once per hand or make your owm. as this file gets generated by XSP you need to have a custom duplicate of it. Antti
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