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
that is not news to do partial reconfig with v2pro in the module-based , but just you said xilinx is really having some new things for v4 PR but whats the new? and someone in the xilinx said v4 have a new bus macro "slice macro" to replace TBUF macro like " bus macro" but what is hell it?Article: 98401
well all I know is that a person who is doing some university research on xilinx partial reconfig, says that he can not do V4 as of today, but will be able todo withing a week time because xilinx is about to release something withing one week, that what I was told, what it is going to be released (if at all) I dont know.Article: 98402
In article <dunp4j$ast22@xco-news.xilinx.com>, Austin Lesea <austin@xilinx.com> wrote: > Of course, I disagree that ASICs have any rosy future at all, and I > also feel that your conclusion that whoever controls the foundry > controls the technology is also quite bizarre. It depends what you mean by ASIC, of course; I can just about imagine a future in which a fair number of the functions we nowadays associate with chipsets are performed in an FPGA (indeed, the Cray XD1's network-chip to processor-chip logic is a large Xilinx chip). I can even nearly imagine one where FPGAs have taken over the job of graphics processors; current graphics processors are pretty much a large grid of floating-point units with interconnect. I don't see one in which the functions we nowadays associate with CPUs in things we think of as computers happen in FPGA: the incentive for greater performance is enough to make it worth doing actual circuit design, and an FPGA containing a credible CPU as a functional block is not going to be competitive with that CPU implemented without the surrounding FPGA. Though this may mean that you end up with an ecosystem containing some FPGA vendors, Intel, and possibly a couple of other CPU manufacturers (IBM, AMD?). I think there will be a role for ASICs when you want to move data around at enormous rates in truly-commodity applications: an eight-port gigabit ethernet switch ASIC, essentially eight gigabit transceivers bought from an IP firm and pasted around the edge of a small amount of routing logic, is in volume going to be cheaper than an FPGA with lots of logic in the middle and eight transceivers around the edge. OK, CISCO's bigger routers are sold at margins where you can afford to buy Virtex4 chips just for the transceivers, but there's a much larger, more price-sensitive market in the home. > And, have you heard anything about that 65nm ASIC process being > ready for anyone, anywhere? For anything? Other than it is too > much money, and too much power? (with no proven IP) As I'm sure you know, Intel has shipped several million 65nm ASICs in the last few months. TomArticle: 98403
"Thomas Womack" <twomack@chiark.greenend.org.uk> wrote in message
news:u9c*pabbr@news.chiark.greenend.org.uk...
> In article <dunp4j$ast22@xco-news.xilinx.com>,
> Austin Lesea <austin@xilinx.com> wrote:
>
> > And, have you heard anything about that 65nm ASIC process being
> > ready for anyone, anywhere? For anything? Other than it is too
> > much money, and too much power? (with no proven IP)
>
> As I'm sure you know, Intel has shipped several million 65nm ASICs in
> the last few months.
I think Austin most likely meant "is anyone selling a 65nm cell-based ASIC
design flow", rather than "is anyone shipping a product based on a
full-custom 65nm process".
As you pointed out, it makes sense for Intel to do deep-submicron design.
But for most people, it's surely far more economical to let (e.g.) Xilinx
solve that particular very hard problem for you. After all, you already have
your own solution space to worry about - graphics, or DSP, or wireless, or
whatever - why focus on anything else?
Cheers,
-Ben-
Article: 98404feedcaseg wrote: > This is just for impementing un a new technology, i have doubts about > how to configure the fpga and how to use the expansion ports, what pins > are enabled for I / O, how can i configure them. I have the archive > in excel about the pins, what can i choose? > In this case a more usefull aproach is to learn about FPGAs in general, then try something simple like a counter, then make a PWM based on the same counter and so on. Have fun, AurashArticle: 98405
Hi xun, you can use a slice-based bus macro, but at this moment, you need to develop it. Of course, as Virtex-4 device has not TBUF the slice-based approach will be used by Xilinx too (I think). I was working with Spartan-3 (it has not TBUFs) and this approach is useful. About the use of partial reconfiguration in Virtex-4, there are some errors using the ISE tools. As the Xilinx people said in previous messages, they are working on it. Regards, Ivan zhangxun0501@gmail.com wrote: > hi everyone > > we know in the virtex-4 there haven't the bus macro so anyone know if > we need the inter-connection between two block how we can do that ???? > > xun >Article: 98406
The data sheet refers you to the Xilinx web site, but I can't find anything there for Virtex-4. Does the Virtex-II CLKFX jitter calculator also work for Virtex-4? Thanks, RobArticle: 98407
In article <1141896195.726430.177200
@u72g2000cwu.googlegroups.com>, offname@gmail.com says...
[ ... ]
> reg [31:0] temp_count=0;
> reg direction=1;
In simulation, you're dealing with software, and
initialization like this works fine.
After synthesis, you're dealing with hardware. If you
want initialization to happen, you have to synthesize
hardware to do it.
That usually means an input signal to your circuit. When
it's asserted, you do initialization. When it's released,
your circuit starts normal operation.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 98408Robj, You can do that to get an estimate. It will be different, but not by that much. I believe the FAEs have the latest jitter predictor, and I am pretty sure that it is built into the latest software release as well. One of the concerns we have had is since the DCM is digital, why would the jitter ever be different from one technology to the next? But, the delay lines are different each time, and the control system gets more sophisticated as we improve the features of the DCM, so the jitter is slightly different. Austin RobJ wrote: > The data sheet refers you to the Xilinx web site, but I can't find anything > there for Virtex-4. Does the Virtex-II CLKFX jitter calculator also work for > Virtex-4? > > Thanks, > Rob > >Article: 98409
In my design I have one Asynchronous FIFO v6.1 that I instantiate twice. When I simulate my design (using Modelsim v 6.0) one of the instantiated FIFOs behaves as expected (in accordance to the datasheet) but the other doesn't. On the offending FIFO, when I assert the READ_ENABLE signal immediately the DATA is presented on the DATA_OUT signal (same clock cycle as when the read enable was asserted). However, the expected (and the behaviour of the first FIFO) is that when READ_ENABLE is asserted the DATA is presented on DATA_OUT one clock cycle later. Does anyone have any ideas why two instantiations of the same FIFO behave so differently? Regards, SimonArticle: 98410
Is the simulation timing of the READ_ENABLE relative to the read clock the same for both instances? <simon.stockton@baesystems.com> wrote in message news:1141923514.369984.207020@z34g2000cwc.googlegroups.com... > In my design I have one Asynchronous FIFO v6.1 that I instantiate > twice. > > When I simulate my design (using Modelsim v 6.0) one of the > instantiated FIFOs behaves as expected (in accordance to the datasheet) > but the other doesn't. > > On the offending FIFO, when I assert the READ_ENABLE signal immediately > the DATA is presented on the DATA_OUT signal (same clock cycle as when > the read enable was asserted). However, the expected (and the behaviour > of the first FIFO) is that when READ_ENABLE is asserted the DATA is > presented on DATA_OUT one clock cycle later. > > Does anyone have any ideas why two instantiations of the same FIFO > behave so differently? > > Regards, > > Simon >Article: 98411
Do you have output registers enabled/disabled in both ? Rgds Andr=E9Article: 98412
Thanks for your replies: John_H: Yes, on the correct FIFO (FIFO A) the DATA appears on FIFO A DATA_OUT one clock cycle (based on the FIFO A READ_CLK) after FIFO A READ_ENABLE is asserted. Similarly on the incorrect FIFO (FIFO B) the DATA appears on FIFO B DATA_OUT the same clock cycle (based on FIFO B READ_CLK) as FIFO B READ_ENABLE is asserted. ALuPin@web.de: I created the Asynchronous FIFO using the Xilinx Coregen Wizard (with output registers disabled) and instantiated it twice in my design. My understanding is that because I am instatiating the same FIFO twice the two FIFOs therefore are identical (in terms of configuration parameters). I have just found out that although in SIMULATION the behaviour of the two FIFOs are different in REAL LIFE (on the hardware using CHIPSCOPE PRO) both FIFO's behave the same (as per the datasheet, ie. as FIFO A is behaving in SIMULATION) Regards, SimonArticle: 98413
<simon.stockton@baesystems.com> wrote in message news:1141927747.728412.138320@u72g2000cwu.googlegroups.com... > Thanks for your replies: > > John_H: Yes, on the correct FIFO (FIFO A) the DATA appears on FIFO A > DATA_OUT one clock cycle (based on the FIFO A READ_CLK) after FIFO A > READ_ENABLE is asserted. Similarly on the incorrect FIFO (FIFO B) the > DATA appears on FIFO B DATA_OUT the same clock cycle (based on FIFO B > READ_CLK) as FIFO B READ_ENABLE is asserted. My question was specifically where the READ_ENABLE is relative to the READ_CLK rising edge. It's easy have two signals that both appear in your graphical timing diagrams to be at the clock edge - identically - but in reality are on different sides of the clock edge. Are both READ_ENABLE signals amply before the rising edge of the clock?Article: 98414
On a project I am working on, I recently had the requirement of embedding an ethernet controller into the system. Since I already had a Cyclone on the board I decided to go with the approach of embedding a NIOS2 processor in the FPGA and adding the phy and other devices necessary to the board. At the moment, I am working on the considerations of how to interface this processor to the rest of the system which contains an Addr, Data, Control bus structure driven by a DSP. Almost all of the devices on the board are memory mapped and can be read or written to as a memory bus cycle. Ultimately, I would like to find a way to allow both processors to share the bus to access the IO devices as needed. In order to do this, I believe I would need to implement some form of bus arbitration scheme that would look at which processor is attempting to use the bus and to assert back a wait signal if the bus weren't ready. From what I have read about the Avalon bus, it sounds as if this should be possible as I read something about variable wait states that can come from the peripherals. I am not certain how to implement these pins in the SOPC builder and I was wondering if someone could help me. Ideally, the NIOS processor would be the bus slave as the DSP has a pin that can be asserted to request the bus from it. When the bus is granted, the DSP places all its signals in the high Z state and other devices can access the bus as desired. The reference documents show examples of putting multiple NIOS2 processors together with a MUTEX on the bus. Unfortunately, I am not certain how this would work with the other processor not being a NIOS2. Can anyone provide some suggestions of how to implement the needded functionality in the NIOS?Article: 98415
Hello Dear friends The board we have designed uses of XC2C256 in its center which distributes and switches between different signals in system. We use of a timing chip which derives the the output of the optical interface of our board. The output clock of the timing chip (named zl_1944_clk) which is very exact is 19.44 MHz which we have connected to the CPLD's GCK0 input pin and assigned this net to an output on one of the ordinary I/O pins to the clock net of the driving ASIC of the optical interface. At this case he measured output jitter on the optical interface is approximately 0.12 UIpp and fluctuates unacceptedly between 0.08 and 0.15. But when the same signal (zl_1944_clk) is input from another input (I/O) port, the output jitter decreases down to 0.05 UIpp. (maenwhile when we bypass the cpld in this net the output jitter is 0.07 and doesn't fluctuate that much.) Besides, when I get the fitter report of the xilinx ISE 6.1i, it says "global clock nets unused".( Although I have connected the zl_1944_clk net to GCK0 pin) I checked my project with ISE 7.1i, too and it did not work, too. I would be grateful if someone help me about this problem and he following questions. 1-Is there any point in using GCK0 pin ? 2-Should I use of timing constraints to make ISE to route my clock signal as desired. I am under pressure and i should deliver the product as soon as possible. thanksArticle: 98416
My advice is that even in an asynchronous FIFO, each side should be properly synchronous to its own clock. Therefore Clock Enable should not change too close to its own clock edge. The two clocks can then be completely asynchronous to each other. Peter Alfke, Xilinx ApplicationsArticle: 98417
Arash Majd wrote: > Hello Dear friends > The board we have designed uses of XC2C256 in its center which > distributes and switches between different signals in system. We use of > a timing chip which derives the the output of the optical interface of > our board. The output clock of the timing chip (named zl_1944_clk) > which is very exact is 19.44 MHz which we have connected to the CPLD's > GCK0 input pin and assigned this net to an output on one of the > ordinary I/O pins to the clock net of the driving ASIC of the optical > interface. At this case he measured output jitter on the optical > interface is approximately 0.12 UIpp and fluctuates unacceptedly > between 0.08 and 0.15. But when the same signal (zl_1944_clk) is input > from another input (I/O) port, the output jitter decreases down to > 0.05 UIpp. (maenwhile when we bypass the cpld in this net the output > jitter is 0.07 and doesn't fluctuate that much.) > Besides, when I get the fitter report of the xilinx ISE 6.1i, it says > "global clock nets unused".( Although I have connected the zl_1944_clk > net to GCK0 pin) > I checked my project with ISE 7.1i, too and it did not work, too. > I would be grateful if someone help me about this problem and he > following questions. > > > 1-Is there any point in using GCK0 pin ? Yes, when it is used to clock internal macrocells; then GCLKs save product terms. It sounds like you are using this as a simple buffer - in that case, any pins can be used - select until you find the lowest jitter ones :) > 2-Should I use of timing constraints to make ISE to route my clock > signal as desired. What does the fitter report say - if this is a simple IN:OUT then the timing constrains cannot do anything. What other signals are routed in the device ? -jgArticle: 98418
On 9 Mar 2006 11:53:24 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >My advice is that even in an asynchronous FIFO, each side should be >properly synchronous to its own clock. Therefore Clock Enable should >not change too close to its own clock edge. >The two clocks can then be completely asynchronous to each other. I agree that this is the way it should be done; I think John_H is asking whether it in fact has been done in this case. Bob Perlman Cambrian Design WorksArticle: 98419
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:44108832$1@clear.net.nz... > > It sounds like you are using this as a simple buffer - in that case, > any pins can be used - select until you find the lowest jitter ones :) Since the clock is 19.44 MHz, the 51.44 ns period should show 0.05 UI of jitter, much less 0.12 UI. I would think much of the jitter problem is in an I/O with ridiculously low drive or a mismatch in voltage levels that leaves the high logic level up to a pull-up resister. I would expect 2 ns at the outside for jitter in a noisy CPLD and would hope for *much* less. Anyone know if there would be benefit to driving the output MacroCell with a TFF in DualEdge mode rather than routing the signal through to the buffer?Article: 98420
John_H wrote: > "Jim Granville" <no.spam@designtools.co.nz> wrote in message > news:44108832$1@clear.net.nz... > >>It sounds like you are using this as a simple buffer - in that case, >>any pins can be used - select until you find the lowest jitter ones :) > > > Since the clock is 19.44 MHz, the 51.44 ns period should show 0.05 UI of > jitter, much less 0.12 UI. > > I would think much of the jitter problem is in an I/O with ridiculously low > drive or a mismatch in voltage levels that leaves the high logic level up to > a pull-up resister. > > I would expect 2 ns at the outside for jitter in a noisy CPLD and would hope > for *much* less. > > Anyone know if there would be benefit to driving the output MacroCell with a > TFF in DualEdge mode rather than routing the signal through to the buffer? Probably not, as the jitter causes, as you suggest, as normally quasi analog effect ( slow rises, etc ). Once the signals are inside the device, and digital, the damage is already done.... The slower the edges, the more common mode impedances in GND and VCC matter. For this type of problem, I'd choose a 'quiet bank' for the buffer, and pins close to the GND pins, with few local aggressors. The OP was a bit vague on what else was going on around this net ... -jgArticle: 98421
See http://www.ht-lab.com/freecores/AES/aes.html No pipelining but perhaps the testbench can save you some time. Hans www.ht-lab.com <manjunath.rg@gmail.com> wrote in message news:1141827140.488659.53020@u72g2000cwu.googlegroups.com... > We have been doing a project on high speed aes using subpippelining > concepts we would be happy if we find some code which may help us.. if > anyone in this group has any access pls help us >Article: 98422
Hi Ben, Just start xmd as you would for debugging on the local machine. Then, on another machine, start the edk frontend for gdb and give it the ip address and port of xmd on the first machine. -GregArticle: 98423
Hey, I'm trying to connect my VHDL core of a PLB bus master to two LEDs to aid me in debugging the hardware as I'm using it. However, when I add the output signals to the design, I get the following errors: ERROR: NgdBuild:467 - output pad net 'plb_master_out_0_LED_0_OBUF' has an illegal buffer ERROR: NgdBuild:467 - output pad net 'plb_master_out_0_LED_1_OBUF' has an illegal buffer I've tried running this signal through an OBUF, but that didn't seem to get me anything. I've tried running it without the OBUF, and I get the same errors. I created the core using the create/import peripherals for a PLB core with 16 slave registers, interrupt support, and master mode. Any help would be appreciated.Article: 98424
Dear EDK experts, Here I am again with an EDK problem... I have a top level ISE design and an EDK submodule (PPC). I am trying to bring a DCR bus out from the EDK submodule into the top level ISE design. Since I want this bus to be in the normal address space I added the opb2dcr_bridge to my design. I assigned the DCR master side of bridge to the external ports of the EDK submodule. All of this seems fine, but it doesn't work... I can't see any activity on the DCR bus when looking with the Chipscope except for I know that the clock is present... What am I missing? One thing I noticed is that in the Bus Interface View the bridge shows as not connected on the DCR master side... I tried adding a DCR bus, connecting the bridge to it and bringing this bus to external ports instead of the bridge's pins directly, however the EDK then would complain that there were no slaves on that bus... The only connections it would allow to that bus in the Bus Interface View are to the ppc405_0 and, I believe, plb2opb_bridge_0... Has anyone been through this? Thanks, /Mikhail
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