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
Mike Treseler wrote: > rickman wrote: > >> What exactly is a "real" reset signal? > > > One that comes in on a device pin. I have a reset signal on a device pin. I connected it to the startup block. That's as far as I care about asynchronous resets. I want my logic to use the free reset inputs on the flip-flops for synchronous sets or resets. Synplify 7.7.1 won't do it. XST won't do it. I tried removing my async reset today. Synth time dropped by 50%. Resource usage dropped by ~5%. It looked like it would've routed much better. (I didn't bother because the result was actually wrong - the initial values weren't preserved.) I want this benefit, but it seems that nobody is doing it. HamishArticle: 75926
If you don't leave holes into your program memory map the default linker script work very well Walter. "Yongjie Liu" <yongjie@home.net> a écrit dans le message de news:20041118192043.7531.YONGJIE@home.net... > Hi, > > I would like to run my program (too big) from external memory. I don't > know how to configure my project in Xilinx Platform Studio to complie it > correctly. What parameter should I modify or is there any configureation > file I should creat? > > Any suggestion or help is greatly appreiciated! > > Thanks > YongjieArticle: 75927
"Steven Sharp" <sharp@cadence.com> wrote in message news:3a8e124e.0411181905.575b897e@posting.google.com... > "Jim Wu" <nospam@nospam.com> wrote in message news:<cngkbn$4m1@cliff.xsj.xilinx.com>... > > > > if (data == 0) begin > > $fwriteb(fd, "%u", data); > > $fseek(fd, 1, 0); > > end > > else > > $fwriteb(fd, "%c", data); > > Shouldn't that be $fseek(fd, -3, 1), to seek backwards > 3 bytes from the current position to compensate for > having written a 4-byte binary word instead of 1 byte? > With $fseek(fd, 1, 0), you are seeking to the second > byte in the file, which is only correct if you were > at the start of the file when you wrote the NUL byte. You are absolutely right. My first posting was to show how to get around the problem that some simulators (e.g. Modelsim) cannot write out the NULL byte. Of course a more general solution is using $fseek(fd, -3, 1) as you pointed out. > Some simulators actually let you write a NUL byte > out with %c, which avoids this nastiness. I know NCVerilog can do this, but not all simulators work this way. JimArticle: 75928
Does anyone have any experience using Xilinx System Generator? I'm curious as to how it's designs stack up against custom RTL for FPGAs. Any metrics would be especially helpful. I am debating using this tool for some digital receiver processing, so it would be creating complex FIR filters, amplitude and phase computation, differentiator, etc. from my Matlab code. Thanks, BrandonArticle: 75929
On 11 Nov 2004 20:31:01 -0800, suntthekid@gmail.com (suntthekid) wrote: > Hello, Jon > From timing analysis in Quartus (my circuit have 2 clock) Fmax of >first clock that the code can run about 75 MHz and another clock(clk2) >can run about 120MHz. the first clock we run at 33.33 MHz (I use this >clock to system clock) and the other clk is used for receive external >signal. and the recieve frequency i try fist is 50 MHz and found >incorrect in the circuit so i decrease recive frequency to 4 MHz and >it is still incorrect. (note: clk2 is use to write signal into RAM and >Clk1 is used to read signal from RAM). before I ask you i simulate >only functional and i will try to simulate follow your suggestion. > when i change option to synthesis the result is different. (i.e. >sometimes state is not change to correct state, some signal is not >change follow i write the code) > Thank you for your sugestion before. and hope to recieve your >next sugestion. thank you very much. > >Cheers, > Sunt and Akaporn What special precautions are you taking for signals that are clocked by the logic on one clock net that are passed to logic that is clocked by the other clock net? Is your RAM dual port, or are the reads and writes (at different frequencies) using the same port? Philip Philip Freidin FliptronicsArticle: 75930
I'm considering the V2pro series for several projects. I've heard from someone with experience that there are problems with the RocketIO when a lot of other things are happening on the chip. This is thought to be a problem with the V2pro package. The evaluation boards only implement the RocketIO without a lot of other things going on in the part. Can anyone provide an example of a successful RocketIO implementation on a real board that also has a lot of parallel IO and heavy use of internal block RAM, etc? Paul Smith Indian University PhysicsArticle: 75931
>I need this for my graduation report. Tragic. On Fri, 12 Nov 2004 10:26:58 +0100, "Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote: >Just to put my aim in perspective: I'm neither trying to fool you nor trying >to get my homework solved (like a given individual presumed). Why I am >talking about a basic condition with respect to the "one D/A converter for >multiple output channels"-configuration is that this single D/A converter >already exists in hardware. It is there, physical, for me to touch, already >bought... And now I want to use this very D/A converter to feed several >output channels. So no touching the DAC, or the board it is on. And you are time multiplexing multiple channels of data through this 1 DAC (how many? I dont really care). >Of course I could buy a DAC for every channel but that's >not my intention. The hardware setup does not allow to solder other devices >on the board. But if you are willing to build sample and hold circuits, you must have some signals which tell you which channel is being sent out on the DAC at any time, so that you would know which sample and hold is to be updated. This also means that you are willing to build more hardware, just not more DACs on the board you have. >So PLEASE just take it as it is! I want to solve the problem >that way. So don't try to proselytize me like that jehovah's witnesses >guys... ;-) (I had a long and tangential response to this. I assure you that you are glad that I replaced it with this note!) >Hope you come up with more constructive suggestions! >Veronica Fine. Be that way. 1) Can't touch the DAC you have. 2) Willing to build hardware after the DAC 3) Have signals that tell you which channel the DAC is currently outputting A) Analog sample and holds droop. Good caps and design can minimize it but "no droop" is impossible over temperature. Constructive Suggestion: Take the DAC output and run it into an ADC. Take the ADC output and register the output into multiple DACs, one per channel. Use your channel select signal to control which DAC gets updated. This design does not touch your board with the DAC. Handles as many channels as you want. Has NO DROOP. Is easier to design than fancy pants low droop S&H, and does not have any expensive low leakage caps, or 0.000nA input current op-amps. Uses less components that the S&H solution. Is probably cheaper than the S&H solution too. For example, the Maxim MAX5732 implements 32 DACs, each with a holding register. Small quantity price is $130 A Maxim MAX1340 with an ADC and 4 DACs on one chip is $21 There are an insane number of options of which ADC and DAC you could choose. Hope that is constructive enough for you. Philip Philip Freidin FliptronicsArticle: 75932
Is it possible to create a parametarizable Megafunction of my own designs in Quartus ? I would like to be able to add my own designs into MegWizard Manager that can be instatiated within *.BDF files as graphic entities with configurable properties (similar to the LPM_XXX functions). ThnxArticle: 75933
Paul, There are many such applications that are successful, and I will let others respond here to that point. As to the use of the MGTs and also using the parallel IOs at or near their SSO guideline limits: yes, this can be an issue. Blame in on the package, blame it on the board, blame it on Xilinx by all means (heck, we put the two in the same package didn't we), but be aware that the customer does have ultimate control over their destiny. What do I mean by that? Well, if you need to use many IOs, near the SSO limits, next to the MGTs, with lots of attenuation on the MGT signals, you should probably be doing a lot of pcb power distribution system simulations, (not to mention full hspice sims of the MGT channels as well!). You should also be looking carefully at all sources of coupling (cross talk, etc.) not just on the board (connectors, vias, grounding, package). Perhaps, one would say that the use of virtual grounds (IOs intentionally set to drive a '0' and then externally grounded) is a good idea bracketing the MGT IOs if simulations are showing a lot of ground and Vcco bounce due to all of the IOs switching? Here, "a lot" is defined as more than 100 mV peak to peak. I mean, when the core voltage is 1.5 volts, or even 1.2 volts, 100 mV of ground bounce is now a significant factor, and not just for the MGTs! Any bounce not addressed increases the system jitter, and hence requires more timing slack for a design to operate reliably. Perhaps you need to double up on ground planes for lowering the return inductance? Xilinx FAEs are more than willing to help customers with challenging SI issues. The user's guides, the demonstration boards, and the RocketLabs(tm) are all their to help you succeed. These represent best practices that should be transferable to your applications. We would much rather have a successful design using lots of chips, than an unsuccessful design with cross talk, ground bounce, and jitter problems. Austin Paul Smith wrote: > > I'm considering the V2pro series for several projects. > > I've heard from someone with experience that there are problems with the > RocketIO when a lot of other things are happening on the chip. This is > thought to be a problem with the V2pro package. The evaluation boards > only implement the RocketIO without a lot of other things going on in > the part. > > Can anyone provide an example of a successful RocketIO implementation on > a real board that also has a lot of parallel IO and heavy use of > internal block RAM, etc? > > Paul Smith > Indian University Physics >Article: 75934
Philip Freidin wrote: (snip) > Take the DAC output and run it into an ADC. > Take the ADC output and register the output into multiple DACs, one > per channel. Use your channel select signal to control which DAC gets > updated. (snip) > Is probably cheaper than the S&H solution too. > For example, the Maxim MAX5732 implements 32 DACs, each with a holding > register. Small quantity price is $130 That is an interesting suggestion. Not so long ago CD players used one DAC with two S&H to save the cost of one DAC. There were people who believed that the phase shift was noticable, though I don't know that there was ever proof of it. It seems that the DAC is now cheaper than the S&H. -- glenArticle: 75935
Yongjie,
What EDK release are you using. The latest EDK 6.3 has a graphical
linker script generation tool that allows you specify where to put
various sections of your program into internal or external memories
present in your system.
Amit.
Yongjie Liu wrote:
>Hi,
>
>I would like to run my program (too big) from external memory. I don't
>know how to configure my project in Xilinx Platform Studio to complie it
>correctly. What parameter should I modify or is there any configureation
>file I should creat?
>
>Any suggestion or help is greatly appreiciated!
>
>Thanks
>Yongjie
>
>
Article: 75936Austin Lesea wrote: (snip) > Here, "a lot" is defined as more than 100 mV peak to peak. I mean, when > the core voltage is 1.5 volts, or even 1.2 volts, 100 mV of ground > bounce is now a significant factor, and not just for the MGTs! Any > bounce not addressed increases the system jitter, and hence requires > more timing slack for a design to operate reliably. Perhaps you need to > double up on ground planes for lowering the return inductance? Some time ago I had suggested using thicker copper to reduce inductance, before realizing that it really doesn't help. (The inductance of a rectangular bar is proportional to the sum of the height and width.) I believe that parallel ground planes will have the same effect. The reduction in resistance might help, though. -- glenArticle: 75937
Hi, I ended up with the following, which works: > task WRITE_BYTE; > input [7:0] data; > integer position; > begin > if (data == 0) > begin > position = $ftell(file_ptr); > position = position + 1; > $fwriteb(file_ptr, "%u", data); > $fseek(file_ptr, position, 0); > end > else > begin > $fwriteb(file_ptr, "%c", data); > end > end > endtask Are you saying that a more concise way to do this would be with a relative seek? I don't have a good reference for these system tasks, the best I could come up with is what I put above, based on reading some web material. But this: > $fseek(fd, -3, 1) Seems much more concise... It's equivalent? EricArticle: 75938
Glen, It does help. Two inductors in parallel is half the inductance. Place them with the power planes next to them, and you also get added bypass capacitance (power/ground sandwiches). Austin glen herrmannsfeldt wrote: > > > Austin Lesea wrote: > > (snip) > >> Here, "a lot" is defined as more than 100 mV peak to peak. I mean, >> when the core voltage is 1.5 volts, or even 1.2 volts, 100 mV of >> ground bounce is now a significant factor, and not just for the MGTs! >> Any bounce not addressed increases the system jitter, and hence >> requires more timing slack for a design to operate reliably. Perhaps >> you need to double up on ground planes for lowering the return >> inductance? > > > Some time ago I had suggested using thicker copper to reduce > inductance, before realizing that it really doesn't help. > (The inductance of a rectangular bar is proportional to the > sum of the height and width.) I believe that parallel ground > planes will have the same effect. The reduction in resistance > might help, though. > > -- glen >Article: 75939
Antti Lukats wrote: > -- sometimes I think its faster easier and cheaper to buy a fresh new PC for > every FPGA toolchain. Get new PC install one application and use it for that > applicaton. What you _could_ do, is have a removable hard drive (cradle adaptor), or maybe one based on newer, very fast serial links. (not as cheap) Then, each tool has its own resource, but you still hope that the windows area remains OK, - the degeneration effects should be reduced. -jgArticle: 75940
Eric, There is just one single product which supports both Windows and Linux: http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=PRODUCTS&sSecondaryNavPick=Design+Tools&key=DS-ISE-BAX Regards, Steve Eric Smith wrote: >If I want the Linux version of BaseX, do I have to do something >special when I order it? Or is there just a single product that >includes both Windows and Linux versions? The online store doesn't >seem to have any provision for specifying the platform. I'd hate >to spend the money and wind up with a version I can't use. > >Thanks, >Eric > >[If you want to reply by private email, please remove the obvious >spam-proofing from my email address.] > >Article: 75941
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > That is an interesting suggestion. Not so long ago CD players > used one DAC with two S&H to save the cost of one DAC. There were > people who believed that the phase shift was noticable, though I don't > know that there was ever proof of it. People that can hear the difference can compensate by sitting 3.86 mm closer to one speaker (at sea level). Correspondingly less for systems using oversampling. For instance, early Philips players used 4x oversampling, so only a 0.965 mm shift would be necessary.Article: 75942
Hamish Moffatt wrote:
> I have a reset signal on a device pin.
> I connected it to the startup block.
What happens if you ignore the startup block
and just modify the process template to
use that reset signal like this
p: process (reset, clk)
begin
if reset = '1' then
dout <= (others => '0');
elsif rising_edge(clk) then
if sync_reset = '1' then -- where needed
dout <= (others => '0');
else
dout <= din;
end if;
end if;
end process;
That ought to synth and route fine and even
sim the same as before.
-- Mike Treseler
Article: 75943I am getting the following error message while building a simple system consisting of bram, ppc, uart, plb bus, opb bus, plb2opb bridge. I am trying to use hardware simulation to verify my design. Any help or pointers is greatly appreciated. thanks swamy Initializing Memory... Checking ELFs associated with PPC405 instance ppc405_0 for overlap... Analyzing file hello/executable.elf... ERROR:MDT - Elf file hello/executable.elf does not reside completely within BRAM memory of processor ppc405_0. ERROR:MDT - Uncheck the `Mark for BRAM Initialization` setting on the software application generating this ELF. INFO:MDT - This ELF file should be downloaded using a debugger, a bootloader or an ACE file. make: *** [implementation/download.bit] Error 1 Done.Article: 75944
Austin Lesea wrote: > It does help. Two inductors in parallel is half the inductance. > Place them with the power planes next to them, and you also get added > bypass capacitance (power/ground sandwiches). That was what I thought, to, until someone reminded me that increasing the wire size for coil inductors doesn't decrease inductance proportionally. It is the mutual inductance, the interaction of the magnetic field between the two, that changes it. If you have alternating ground and power, and the currents are equal (and opposite) then it might be true. (That is, more transmission line like, and less wire like.) For I/O pin current, going out traces that can't cancel the magnetic field of the ground plane current, I think it isn't true. The additional capacitance does help, though. -- glenArticle: 75945
Glen, That's right. The inductance depends on the area of the loop the current takes. The plane inductance on it's own isn't important, it's the loop area of the trace and the plane that matters. What another plane can do is lower the loop area. If a trace always close to one or other tightly coupled planes, the loop area is small. If you only have one ground plane, it can be harder to keep the trace close to it on a multi-layer board. Also, forget about making bypass capacitors out of power and ground planes at the frequencies of interest for FPGAs. The tiny amount you can make is pissed away by the inductance of the vias, PCBs traces and FBGA traces. Best, Syms. "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:cnm07f$nv3$1@gnus01.u.washington.edu... > > > Austin Lesea wrote: > > > > It does help. Two inductors in parallel is half the inductance. > > > Place them with the power planes next to them, and you also get added > > bypass capacitance (power/ground sandwiches). > > That was what I thought, to, until someone reminded me that increasing > the wire size for coil inductors doesn't decrease inductance > proportionally. It is the mutual inductance, the interaction of the > magnetic field between the two, that changes it. > > If you have alternating ground and power, and the currents are equal > (and opposite) then it might be true. (That is, more transmission line > like, and less wire like.) For I/O pin current, going out traces > that can't cancel the magnetic field of the ground plane current, > I think it isn't true. The additional capacitance does help, though. > > -- glen >Article: 75946
On Fri, 19 Nov 2004 11:37:39 -0500, Paul Smith wrote: > > I'm considering the V2pro series for several projects. > > I've heard from someone with experience that there are problems with the > RocketIO when a lot of other things are happening on the chip. This is > thought to be a problem with the V2pro package. The evaluation boards > only implement the RocketIO without a lot of other things going on in > the part. > > Can anyone provide an example of a successful RocketIO implementation on > a real board that also has a lot of parallel IO and heavy use of > internal block RAM, etc? > > Paul Smith > Indian University Physics One of my InfiniBand Core customers is using RocketIO on the V2P20-6, it's working fine for them. http://www.polybus.com/ib_link_layer_website/Article: 75947
Symon wrote: > That's right. The inductance depends on the area of the loop the current > takes. The plane inductance on it's own isn't important, it's the loop area > of the trace and the plane that matters. OK, yes, I agree. A ground plane closer to the signal lines will reduce the inductance. > What another plane can do is lower the loop area. If a trace always close to > one or other tightly coupled planes, the loop area is small. If you only > have one ground plane, it can be harder to keep the trace close to it on a > multi-layer board. > Also, forget about making bypass capacitors out of power and ground planes > at the frequencies of interest for FPGAs. The tiny amount you can make is > pissed away by the inductance of the vias, PCBs traces and FBGA traces. Well, put more vias in parallel, which will reduce the inductance somewhat. The inductance should depend on the length, but it is still likely higher than one would like it to be. -- glenArticle: 75948
Hamish Moffatt wrote: > > Do you mean initialised as in > signal x: std_logic_vector(7 downto 0) := (others => '1'); > That's the one... > > I tried the former and couldn't see any sign of Synplify > using the initial value. > I'll rummage around and see if I can find/recreate a test case from the last time I worked on this in Synplify. I've definitely coded initialized registers that way using XST, which builds the desired single FF implementation, having say both an INIT1 and a sync clear as seen in fpga_editor. BrianArticle: 75949
Hello All, Is it possible to use spartan3 for 5V PCI interface? I seems that there is no problem to use for 3.3V PCI interface. Thanks in advance.
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