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
Sounds like a tough newsgroup day for you, Antti. I hope tomorrow is a much better experience. At home I switched to "thunderbird" (a netscape/mozilla offshoot) and have had a decent time with posting there. "Antti Lukats" <antti@openchip.org> wrote in message news:e9gkdo$sfn$1@online.de... > "Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag > news:e9gj1o$pqj$1@online.de... >> WebPack and SP1 are available but it looks like the ISE WebPack does not >> support any Virtex-5 devices at all? I did assume smallest Virtex-5 would >> be supported. what a pity. >> >> Antti >> > ops, I posted incorrectly as reply. sorry. > and another ops, 5 seconds ago claimed that I already said sorry, but that > sorry was sent to the OP only not as reply to me wrong posting > > Antti >Article: 105201
Andy wrote: > It is important to have a reset that is synchronously deasserted > relative to every clock used. These may be fully syncrhonous resets or > asynchronous resets that have the trailing edge syncrhonized. > > The reason for this is that if a reset input is not syncrhonized to the > same clock as the circuitry being reset, then all flops in the circuit > will not come out of reset on the same clock, which, unless it is > handled very carefully, will cause problems that can be very hard to > debug. > > Whether or not you have a separate reset, or are only resetting on > configuration, the above requirements hold true. > > Andy > > > Nial Stewart wrote: > > "Thomas Reinemann" <thomas.reinemann@aucotronics.de> wrote in message > > news:e981ph$ur5$1@news.boerde.de... > > > Hello, > > > usually a reset signal is applied to put the FFs of an FPGA into a known > > > state. Just some days ago I had a discussion. Someone's point of view > > > is, that a reset is not necessary, since the FF's output will be always > > > zero, after applying the voltage. Does this happen in FPGAs really, > > > especially in a Spartan3? > > > Bye Tom > > > > > > If you use any form of PLL/DLL in your design I don't think you can > > be sure of what's going to happen until it's locked. This can throw > > logic/state machines into complete disarray. > > > > I generate a synchronous reset which de-activates some period > > after all my PLLs have locked. > > > > > > > > Nial One of my current designs has a AC97 and GSM modem PCM interface to a Bluetooth link, multiplexed. This link may obviously be switched from one to the other (yes, I play system sounds across bluetooth ;) at any time. i.e. relatively asynchronous events. The other thing is GSM PCM data is 8k frame rate, AC97 can be up to 192k, variable rate (you have to extract valid data) so there are retimers for the data stream, which is simple enough if you only have one source; with two or more it becomes imperative to ensure clean switching. I have to make sure when I switch into either mode that the state machine for data reframing is in a known state, so at every switch I assert an synchronous reset to the retimer - in reality the switching signal is synchronised to the frame generator so I am guaranteed to switch cleanly from one input to the other and change the rates at which I retime. Reset costs one pin and saves untold misery Cheers PeteSArticle: 105202
Antti Lukats wrote: > WebPack and SP1 are available but it looks like the ISE WebPack does not > support any Virtex-5 devices at all? I did assume smallest Virtex-5 would be > supported. what a pity. Antti Someone in Xilinx should send you whatever is needed, to work with Virtex-5 :) [Peter?] More generally, I can only guess they are trying to throttle demand from the wider user base (to Xilinx, the "great unwashed"), for parts that are still very green. Problem is, that mindset can get you into trouble : if users cannot even synthesise an older design, to see how fast a V5 might be, then V5 goes off their radar pretty quickly. [ It also means the bugs in V5 will hang about longer.... ] If Lattice and Altera DO allow the newest-process leading-devices to be timed, in their free tools, then Xilinx can loose out, and never realise it is happening. This type of voting with the feet, is done silently. -jgArticle: 105203
The older names Broaddown, Raggedstone, Swinyard, Hollybush are hills in the local Malvern Hills chain and if you search around you can even see pictures of them on other websites. Moel-Bryn is the ancient celtic name for Malvern or "Bald Hill" as far as I understand. We even have remains on the hills of iron age fortifications to go with all that. The newer names we are now taking from the Galloway hills in southern Scotland. So far we are using Tarfessock and as of a couple of days ago Darnaw. We might even give some prizes for correct pronounciation when we get the more difficult one. Tarfessock is a bit of a mouthful already but there is much interesting to come yet. I'm sure were going to have lots of fun. John Adair Enterpoint Ltd. Martin Thompson wrote: > "John Adair" <g1@enterpoint.co.uk> writes: > > > It's now been christened and had the obligatory bottle of Champers > > smashed. Darnaw1 is the name to look for. > > > > Go on John, enlighten us :-) Where do you get your names from? Do you > just open a random OS (that's Ordnance Survey for non-Brits - not > operating system!) map and stick your finger on a remote village or > something? > > Cheers, > Martin > > -- > martin.j.thompson@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technology > http://www.trw.com/conektArticle: 105204
I have a project where I will have a large array of V4 FPGAs. Each chip is intended to connect to its four orthogonal neighbors with no intervening logic. I would like the number of bus connections between chips in any direction in the array to be 150 (600 total I/O per chip). The connections will be bi-directional. The distance between chips will be the minimum I can have with sockets, heat sinks (with individual fans), good layout and noise control. Some of the lines, what ever is necessary, will be used for clock and framing for the bus data signals. I would like to use DDR. During bus transfers, all the lines on opposite sides of the chip will be operating and the other two sides will be quiescent. I'm hoping for a bus clock of 150 MHz. Comments? ;=) Marco ________________________ Marc Reinig UCO/Lick Observatory Laboratory for Adaptive OpticsArticle: 105205
Symon wrote: > "Ben Jones" <ben.jones@xilinx.com> wrote in message > news:e9gfcl$4mg1@cliff.xsj.xilinx.com... > > > > Hope this makes sense... perhaps someone can take it a step further and > > work > > out where the 56 levels thing really comes from (and thus deduce what this > > particular synthesis tool believes the LUT:CY speed ratio is!). > > > > Cheers, > > > > -Ben- > > > Hi Ben, > Thanks for that, it made sense to me. I think we might need to know what > part the design was in because the carry chain length is limited by the > number of rows in the FPGA. Smaller parts have smaller maximum length > chains. Also, as a BTW, I see from the datasheet that the ORCY structure > that was in V2PRO has been dropped from the V4. That made wide gates even > faster. It makes some sense, but I think the fastest approach is to use combinations in layers. With the large discrepancy in speed, it makes sense to use a lot of input in a single carry chain. But the carry chain is by nature serial and the delays keep adding. The delays with LUTs can be done in parallel using a pyramid structure. I think the fastest approach would be to combine the two in a pyramid of LUTs and carry chains like they have been discussing above. One way to compare the two is to consider building up from a single LUT. With four inputs to a LUT, you can combine four single LUTs to another LUT for 16 inputs with two LUT delays. Using the 12:1 approximation for the ratio of delays in the two, you can combine 12 LUTs for 48 inputs and get two LUT delays using the carry chain. Clearly this is faster on the first level. So let's consider increasing the size by a factor of four by combining four, 48-input carry chains using a LUT. This will give 192 inputs with three LUT delays. To do that in a longer carry chain, you would get 5 LUT delays. So clearly it is better at some point to break the carry chains and combine their outputs with a LUT. I am assuming that you can not run one carry chain into another without using a LUT. In fact, I seem to recall that to get an output from a carry chain you need to use a LUT. So maybe my delay calculations are flawed since the 12:1 ration does not account for the required end of chain LUT. In fact, I am pretty sure that makes the carry chain slower than a pyramid of LUTs. Anyone know the details of connecting the output of the carry chain in V4 parts?Article: 105206
Hi Christian, FSL is awesome, but remember that the CPU must handle every piece of data in the channel. Putting the CPU in the datapath is something high-speed designers usually try to avoid. There's no such thing as DMA to an FSL connection (though sometimes I wish there was). You can use the DMA functionality on Xilinx's OPB IPIF, but it tends to produce massive cores. Look for example at the size difference between the ethernet MAC with and without SGDMA. Also, there's the standalone opb_dma controller, but it's not as efficient as an IPIF-integrated controller. Choices and tradeoffs, as always. More below: Christian Schleiffer wrote: > The hardware interface is no problem at all and my bus connection will > have a system synchronous part as well. Maybe I even don't have to worry > about IRQs: the controller will be running uCLinux and I just read about > an official FSL driver doing the polling job. I have to get deeper into > that uCLinux stuff first, I think. I'm familiar with the uClinux driver you mention, since I wrote it. And, once again the biggest problem there is throughput because all data over the channels must be handled by the CPU. It is possible to trigger interrupts on FSL status, but you have to do some crafty stuff in the MHS file. Basically co-opt the FSL's has_data or is_full signals and bring them into the interrupt controller. >>As far as data rate, The read and write FIFO is synschrounous to your >>microblaze clock. I think it is a single cycle instruction to to a >>non-blocking write to a FSL. Could take 2 or more but I can't remember. > > Yes, non-blocking write and read operations take 2 instruction cycles. Multithreaded operating systems or apps *must not* use blocking FSL operations, since they'll lock you up hard if you do a blocking read/write on an empty/full channel. Instead, you have to simulate it by doing a nonblocking read, testing the status, and repeating if required. This slows things down a lot. If you know exactly how many items should be in the channel, you might get away with a blocking op. Regards, JohnArticle: 105207
rickman wrote: > It makes some sense, but I think the fastest approach is to use > combinations in layers. With the large discrepancy in speed, it makes > sense to use a lot of input in a single carry chain. But the carry > chain is by nature serial and the delays keep adding. The delays with > LUTs can be done in parallel using a pyramid structure. I think the > fastest approach would be to combine the two in a pyramid of LUTs and > carry chains like they have been discussing above. > > One way to compare the two is to consider building up from a single > LUT. With four inputs to a LUT, you can combine four single LUTs to > another LUT for 16 inputs with two LUT delays. Using the 12:1 > approximation for the ratio of delays in the two, you can combine 12 > LUTs for 48 inputs and get two LUT delays using the carry chain. > Clearly this is faster on the first level. > > So let's consider increasing the size by a factor of four by combining > four, 48-input carry chains using a LUT. This will give 192 inputs > with three LUT delays. To do that in a longer carry chain, you would > get 5 LUT delays. So clearly it is better at some point to break the > carry chains and combine their outputs with a LUT. I am assuming that > you can not run one carry chain into another without using a LUT. In > fact, I seem to recall that to get an output from a carry chain you > need to use a LUT. So maybe my delay calculations are flawed since the > 12:1 ration does not account for the required end of chain LUT. In > fact, I am pretty sure that makes the carry chain slower than a pyramid > of LUTs. > > Anyone know the details of connecting the output of the carry chain in > V4 parts? In the Spartan3E parts (things may vary for the Virtex4) the exit from a MUXCY (as opposed to an XORCY used in an adder) can be directly onto routing. The timing report will go straight from a Tbyp delay to the net. For 4^n inputs ORed in a LUT tree (or pyramid) the additive delay will be n*Tilo+(n-1)*Tnet. For one carry chain, the additive delay will be Topcyf+((4^n)/8-1)*Tbyp. For my Spartan3E, -5 speed grade, the carry chain is better at n=2-4; I'm surprised the numbers work for n=2 but that comes from a history where carry chains were tough to get on and off (here we only have to sweat getting on the carry chain, off is free). If the problem were a 256-wide OR or a 16k-wide OR, an extra level of LUTs would work out well with one or two carry chain stages, respectively. The numbers may skew slightly for other families but the timing reports will show what the makeup is for the various paths - including routing - to make a better determination of what's "best."Article: 105208
On Sat, 8 Jul 2006 13:12:43 +0200, "Jan Hansen" <someone@microsoft.com> wrote: >I have switched from an Intel Pentium 4 1.4 Ghz 0.5 GB RAM to an AMD Athlon >64 dual core 2 GHz 2GB RAM, and processing time for my project vent down >from about 17 min to about 4 min.....! And it lookes like ISE utillises >both cores, according to task manager the load are about 50% on each core >during processing...that leaves enough proc. power to read the news without >degrading XST performance. Multiple cores is the future ! While it is true that both CPUs show about 50% utilization, this is not ISE running multi-threaded. What you are seeing is the load sharing that the MS operating system does with systems with 2 CPUs. Basically, at every system call (disk, screen, mouse, clock, network, or other interrupt) the OS will chose which CPU the task runs on after the return from call/interrupt. It tends to try and even things out. The graph that you see in task manager is based on the average load of the CPU over a period of time that tends to be longer that the rate at which calls to the OS occur, and so what you see looks like 50%. If the display used faster sampling, what you would see is it bouncing between 100% and 0%, and alternating between the 2 CPUs. The net affect is that you get approximately the MIPs of 1 CPU at 100%. The other 100% is available for important things such as reading news and posting articles. If ISE was multi-threaded, you would see both processors at close to 100%. Note that this switching back and forth is slightly less efficient due to the cache contents of each CPU. You can force the OS to only run a specific task on 1 CPU as follows: Once the task is running, open task manager on the processes tab. Select the task (i.e. ISE or XST or P&R) then click the right mouse button to get the context menu. Select "Set Affinity", and you will see a list of available CPUs, with a tick against all of them. Turn one of them off. Your task will now only run on that CPU. If you now look at the graphs, you will see one CPU at 100% and the other is running pretty much everything else. Cheers, Philip Philip Freidin FliptronicsArticle: 105209
Hello Group. Quite simple question... but I cannot seem to be able to find the answer: Given a Code Image initially targeted for a Stratix EP1S40F780C8 - i.e. Speed Grade "-8" - would it then be without troubles to load and run that Image on the corresponding "-6" device...? The need for the question arises in the crossfire of device availability and the wish of having only one Coding Image to update. Thanks in advance & best regards, Jesper.Article: 105210
Hi,
I am trying to do the post_par simulation of the opercore ddr
controller(from opencore.org)
There is feedback clk in this design which is said to be routed
externally to the ddr_clk. Since i cannot do this in the board i am
trying to route it througth the fpga for the maximum delay possible. My
problem is whenever i try to route the clock i am getting the error
message
"Pack 1569: the dual data rate register i_ddr_sdr/fddrd/u1 failed to
join a OLOGIC component as required"
i didnt understand the meaning of this error. I tried to generate extra
clk(similar to ddr_clk using the fddrrse) but the getting the same
error.
regards
subin
Article: 105211Hello all I have implemented the typicall "hello world" in a spartan3 with: - 1 MBlaze. - 2 LMB buses (instructions and data) - 1 BRAM - 1 OPB bus with an UARTLITE. Basically i have followed this tutorial step by step : http://www.eece.unm.edu/xup/spartan2emicroblaze.htm (using an spartan-3) The system sends the "hello world" string continuously trought the UARTLITE. But i have any problem with my reset signal, because when i push the reset button, sometimes the system gets block completely. somebody can help me?Article: 105212
Standards like SSTL are good for this due to the low signal swing. The biggest decision is if to use DCI which burns more power in the V4 or to use external resistors which take board area and make routing more difficult. The other decision is weither you use source synchronous clocking or a common clock approach. At 150 Mhz the common clock is slightly marginal depending on how long tracks are, speed grade, etc. unless you use some DCM based techniques. You can generate a clock that is offset from the common clock a little by using a DCM and use that as clock for register input to gain more time. Alternatively you can use a DCM to null out the clock to output time and get more margin from that. John Adair Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development Board. http://www.enterpoint.co.uk "Marc Reinig" <Marco@newsgroups.nospam> wrote in message news:44bc1fed@darkstar... >I have a project where I will have a large array of V4 FPGAs. Each chip is >intended to connect to its four orthogonal neighbors with no intervening >logic. I would like the number of bus connections between chips in any >direction in the array to be 150 (600 total I/O per chip). The connections >will be bi-directional. The distance between chips will be the minimum I >can have with sockets, heat sinks (with individual fans), good layout and >noise control. Some of the lines, what ever is necessary, will be used for >clock and framing for the bus data signals. I would like to use DDR. >During bus transfers, all the lines on opposite sides of the chip will be >operating and the other two sides will be quiescent. I'm hoping for a bus >clock of 150 MHz. > > > Comments? ;=) > > Marco > ________________________ > Marc Reinig > UCO/Lick Observatory > Laboratory for Adaptive Optics > >Article: 105213
"John Adair" <g1@enterpoint.co.uk> writes: > The older names Broaddown, Raggedstone, Swinyard, Hollybush are hills > in the local Malvern Hills chain and if you search around you can even > see pictures of them on other websites. Moel-Bryn is the ancient celtic > name for Malvern or "Bald Hill" as far as I understand. We even have > remains on the hills of iron age fortifications to go with all that. > > The newer names we are now taking from the Galloway hills in southern > Scotland. So far we are using Tarfessock and as of a couple of days ago > Darnaw. We might even give some prizes for correct pronounciation when > we get the more difficult one. Tarfessock is a bit of a mouthful > already but there is much interesting to come yet. I'm sure were going > to have lots of fun. > I knew geography had to be in there somewhere :-) Thanks! Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 105214
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:1153186786.804902.220530@h48g2000cwc.googlegroups.com...
> Anyone know the details of connecting the output of the carry chain in
> V4 parts?
The quickest way off the carry chain, believe it or not, is to use the XORCY
element (with a 0 input from the fabric, or a 1 if you want inversion). This
is faster than going up to the next LUT and using the dedicated output. This
still takes a few hundred picoseconds though (check the timing files for the
exact number).
<plug> In Virtex 5, the carry chain structure has got *much* faster relative
to the rest of the fabric, both in terms of propagation delay and time to
get on/off the chain... :-) </plug>
Cheers,
-Ben-
Article: 105215> There is feedback clk in this design which is said to be routed > externally to the ddr_clk. Since i cannot do this in the board i am > trying to route it througth the fpga for the maximum delay possible. well - the idea is to compensate the IOB delay for the clock with your DCM. This gives you an internal clock that is phase aligned to your external clock ... just delaying by "the maximum possible" will lead you nowhere ... you could try to use one DCM to phase shift your internal clock by an adjustable amount and route this clock to you RAM ... you would then have to manually set the delay to phase align internal/external clock bye, MichaelArticle: 105216
Ben Jones wrote: > > <plug> In Virtex 5, the carry chain structure has got *much* faster relative > to the rest of the fabric, both in terms of propagation delay and time to > get on/off the chain... :-) </plug> Hi Ben, Great, so does that mean Webpack will (soon?) allow designers to actually use the Virtex 5 family ? -jgArticle: 105217
"subint" <subin.82@gmail.com> wrote in message news:1153200381.707271.324810@p79g2000cwp.googlegroups.com... > Hi, > I am trying to do the post_par simulation of the opercore ddr > controller(from opencore.org) > There is feedback clk in this design which is said to be routed > externally to the ddr_clk. Since i cannot do this in the board That statement right there says that you need to stop and re-read how to use the core and DDR. The whole point of the feedback clock in any DDR design is to compensate for PCB delays. Trying to emulate these delays in some manner is exactly the wrong approach. KJArticle: 105218
Hi am using FFT core (VHDL model) and simulated using modelsim-xilinx edition without any problem. Did you update your model sim simulator with latest updates ? rgds bijoyArticle: 105219
"Ben Jones" <ben.jones@xilinx.com> wrote in message news:e9i89j$63f1@cliff.xsj.xilinx.com... > > <plug> In Virtex 5, the carry chain structure has got *much* faster > relative > to the rest of the fabric, both in terms of propagation delay and time to > get on/off the chain... :-) </plug> > Hi Ben, C'mon, dish the numbers! :-) Is it looking ahead further, or has the chain itself got faster? Cheers, Syms.Article: 105220
Hi all, I have a JED file for an old PAL device and I have to put this design in an EPLD. Is there a tool that can read the JED file and translate it to any usable language (vhdl, verilog or other ) ??? Have you any tip for this handling JED files ?? Thanks. Stéphane.Article: 105221
hi,
ok. so i need to delay the clock using the dcm. fine .but
anyone can tell me what is the error message means ""Pack 1569: the
dual data rate register i_ddr_sdr/fddrd/u1 failed to
join a OLOGIC component as required"
This error is showing when i try to touch (route) the ddr_clk for
delaying it.
regards
subin
KJ wrote:
> "subint" <subin.82@gmail.com> wrote in message
> news:1153200381.707271.324810@p79g2000cwp.googlegroups.com...
> > Hi,
> > I am trying to do the post_par simulation of the opercore ddr
> > controller(from opencore.org)
> > There is feedback clk in this design which is said to be routed
> > externally to the ddr_clk. Since i cannot do this in the board
>
> That statement right there says that you need to stop and re-read how to use
> the core and DDR. The whole point of the feedback clock in any DDR design
> is to compensate for PCB delays. Trying to emulate these delays in some
> manner is exactly the wrong approach.
>
> KJ
Article: 105222I am using EDK 7.1 and trying to determine if the built in capabilties of the flashwriter tool will suffice for our board. On pg 153 of the Embedded tools manual there is a table with this entry: "Paired x16 only capable devices in x16 mode, forming a 32-bit data bus" Our config is Paired x16 devices, but they are also 8 bit capable. We have them connected for 16 bit mode only. The parts are Spansion S29AL032D (Model 03). Can anyone tell me if this will work? (The wording from the EST Manual is vague to me. I'm currently plowing through the flashwriter source to try to understand.)Article: 105223
"Symon" <symon_brewer@hotmail.com> wrote in message
news:44bcd307$1_1@x-privat.org...
> "Ben Jones" <ben.jones@xilinx.com> wrote in message
> news:e9i89j$63f1@cliff.xsj.xilinx.com...
> >
> > <plug> In Virtex 5, the carry chain structure has got *much* faster
> > relative
> > to the rest of the fabric, both in terms of propagation delay and time
to
> > get on/off the chain... :-) </plug>
> >
> C'mon, dish the numbers! :-) Is it looking ahead further, or has the chain
> itself got faster?
So, each slice now has four LUTs and four FFs. Consequently, there are four
MUXCY/XORCY pairs in each slice's subchain. The Tbyp (i.e. cin-to-cout
delay) for the slice is on the order of 80ps. So that works out to around
20ps per LUT, or twice as fast as in Virtex-4.
I am not a sub-micron designer, so I don't really know how they achieved it
:) but I'll bet it's a combination of the two factors you mentioned.
Cheers,
-Ben-
Article: 105224
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:44bcbff9$1@clear.net.nz...
> Ben Jones wrote:
> >
> > <plug> In Virtex 5, the carry chain structure has got *much* faster
relative
> > to the rest of the fabric, both in terms of propagation delay and time
to
> > get on/off the chain... :-) </plug>
>
> Hi Ben,
> Great, so does that mean Webpack will (soon?) allow designers to
> actually use the Virtex 5 family ?
I, like you, am surprised that it doesn't (even in the 8.2i release).
Doubtless there is a justification somewhere in terms of reduced burden on
the technical support hotline or some-such... bah!
Then again, the full ISE suite isn't all that expensive... <ducks> :)
Cheers,
-Ben-
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