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
Generally speaking, it is not good, if a module's combinatoral logical delay plus the routing delay exceed the clock period. A certain module calculates a 100-bit accumulation in approxinately 5ns (in a Virtex 5LXT-1). However, the design clock period is 4ns. I could break the sum logic into two pieces, register the high-50-bits, adding the low-50-bits into a register, adding the registered high-50-bits with carry from the low-50-bits, and finally concatenate the high-50-bit sum with the registered low-50-bit registered sum. That would satifiy timing requirements. Howerver, the extra 100-bits of register resources does not seem offer a benefit and likely increases the likelyhood that a larger device will be required. There could be hundreds of these 100-bit adders in the design. So, the module calculates the 100-bit accumulation in one go, taking 5ns and 100 less registers than the preceeding example. Obviously, the input terms must remain stable for two clock periods for the sum to be valid and this is accounted for in the upper logic layers. My issue is how to tell the ISE tool-chain that the 5ns total delay is acceptable in these modules. The Constraints Guide may cover this issue, but I do not see it. Can someone give me an example of the appropriate constraint usage? Thanks in advance. - SamArticle: 132576
On Jun 1, 5:00=A0pm, "Sam Worth" <no-re...@some.org> wrote: > Generally speaking, it is not good, if a module's combinatoral logical del= ay > plus the routing delay exceed the clock period. > > A certain module calculates a 100-bit accumulation in approxinately 5ns (i= n > a Virtex 5LXT-1). However, the design clock period is 4ns. > > I could break the sum logic into two pieces, register the high-50-bits, > adding the low-50-bits into a register, adding the registered high-50-bits= > with carry from the low-50-bits, and finally concatenate the high-50-bit s= um > with the registered low-50-bit registered sum. That would satifiy timing > requirements. Howerver, the extra 100-bits of register resources does not > seem offer a benefit and likely increases the likelyhood that a larger > device will be required. There could be hundreds of these 100-bit adders i= n > the design. > > So, the module calculates the 100-bit accumulation in one go, taking 5ns a= nd > 100 less registers than the preceeding example. Obviously, the input terms= > must remain stable for two clock periods for the sum to be valid and this = is > accounted for in the upper logic layers. > > My issue is how to tell the ISE tool-chain that the 5ns total delay is > acceptable in these modules. The Constraints Guide may cover this issue, b= ut > I do not see it. Can someone give me an example of the appropriate > constraint usage? > > Thanks in advance. > > - Sam I would create two accumulators and drive their Enable inputs at half frequency, in counterphase. Peter AlfkeArticle: 132577
"Sam Worth" <no-reply@some.org> wrote in message news:4843384c$0$12931$4c368faf@roadrunner.com... > > So, the module calculates the 100-bit accumulation in one go, taking 5ns > and 100 less registers than the preceeding example. Obviously, the input > terms must remain stable for two clock periods for the sum to be valid and > this is accounted for in the upper logic layers. > > My issue is how to tell the ISE tool-chain that the 5ns total delay is > acceptable in these modules. The Constraints Guide may cover this issue, > but I do not see it. Can someone give me an example of the appropriate > constraint usage? > > Thanks in advance. > > - Sam Hi Sam, Read the constraints guide. Also, Google this:- multi cycle path NET "clock_en" TNM=FFS "clock_enable"; TIMESPEC TS1 = FROM : clock_enable : TO : clock_enable : 8ns ; HTH., Syms.Article: 132578
Sam Worth wrote: > Generally speaking, it is not good, if a module's combinatoral logical delay > plus the routing delay exceed the clock period. I believe there have been designs that depended on the delay being long enough. > A certain module calculates a 100-bit accumulation in approxinately 5ns (in > a Virtex 5LXT-1). However, the design clock period is 4ns. I would say that 5ns is too close, and for FPGA that you can't predict the times that well, anyway. There are many stories about Cray and his computers related to logic delay. (There is also the Cray-2 resonant box story, where to accomplish a 4ns clock cycle they designed a box resonant at 250MHz. Unfortunately, the clock cycle ended up being 4.2ns, and much delay in product release.) > I could break the sum logic into two pieces, register the high-50-bits, > adding the low-50-bits into a register, adding the registered high-50-bits > with carry from the low-50-bits, and finally concatenate the high-50-bit sum > with the registered low-50-bit registered sum. That would satifiy timing > requirements. Howerver, the extra 100-bits of register resources does not > seem offer a benefit and likely increases the likelyhood that a larger > device will be required. There could be hundreds of these 100-bit adders in > the design. FPGAs usually have so many FF's that registers are free. Without knowing anything else about the design, though, pipelining is usually a good thing. The question always is where to put the pipeline registers for best effect. > So, the module calculates the 100-bit accumulation in one go, taking 5ns and > 100 less registers than the preceeding example. Obviously, the input terms > must remain stable for two clock periods for the sum to be valid and this is > accounted for in the upper logic layers. Is there no other loss in reducing the clock rate for that part of the design? -- glenArticle: 132579
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1778944e-c20b-4263-9979-de97a3ad80d7@z24g2000prf.googlegroups.com... I would create two accumulators and drive their Enable inputs at half frequency, in counterphase. Peter Alfke That sounds interesting and something I would like to learn about. Do you have an example of such technique? - SamArticle: 132580
Sam Worth wrote:
> "Peter Alfke" <alfke@sbcglobal.net> wrote in message
> I would create two accumulators and drive their Enable inputs at half
> frequency, in counterphase.
> Peter Alfke
>
> That sounds interesting and something I would like to learn about. Do you
> have an example of such technique?
Follow the red wire here for two register banks
on opposite enable phases:
http://mysite.verizon.net/miketreseler/count_enable.pdf
-- Mike Treseler
Article: 132581
Mike Treseler wrote:
> Sam Worth wrote:
>> "Peter Alfke" <alfke@sbcglobal.net> wrote in message I would create
>> two accumulators and drive their Enable inputs at half
>> frequency, in counterphase.
>> Peter Alfke
>>
>> That sounds interesting and something I would like to learn about. Do
>> you have an example of such technique?
>
> Follow the red wire here for two register banks
> on opposite enable phases:
> http://mysite.verizon.net/miketreseler/count_enable.pdf
sorry. Make that:
http://mysite.verizon.net/miketreseler/stack.pdf
-- Mike Treseler
Article: 132582Ray Andraka wrote: > Well, does this http://www.andraka.com/shortwave.htm demo project > count? I did it as a demo back in early 2003. It worked surprisingly > well considering there is no analog front end. Very cool! Any plans to publish more details of the design? Best regards, EricArticle: 132583
I am running a simulation after synthesis and I am getting the following error. ** Error: C:/Modeltech_xe_starter/library/lib18.v(9835): $hold( posedge CK &&& (flag == 1):54 ns, posedge E:54 ns, 500 ps ); lib18.v is a library with various net delays. I dont have anything setup for setup and hold in my verilog testbench. I am getting the same error, no matter what frequency I run the master clock at. How do I get rid of this error? Currenty the master clock is running at 200MHz(4 ns period) Your help would be appreciatedArticle: 132584
On Jun 2, 9:08=A0am, FP <FPGA.unkn...@gmail.com> wrote: > I am running a simulation after synthesis and I am getting the > following error. > > ** Error: C:/Modeltech_xe_starter/library/lib18.v(9835): > $hold( posedge CK &&& (flag =3D=3D 1):54 ns, posedge E:54 ns, 500 ps ); > > lib18.v is a library with various net delays. I dont have anything > setup for setup and hold in my verilog testbench. I am getting the > same error, no matter what frequency I run the master clock at. How do > I get rid of this error? > Currenty the master clock is running at 200MHz(4 ns period) > The reported error appears to be a hold time violation which means that the signal is not remaining stable for the required amount of time after the rising edge of the clock. To fix. 1. Identify exactly which signal it is 2. Determine if this is a design error or a modelling error and then apply the appropriate fix. 3. Re-run the simulation. As a first guess, it is likely that your testbench signals get generated on the rising edge of your clock input and then go into your design. But if the design has some non-zero hold time requirement then the testbench inputs will be changing before the required time and generate the error that you're seeing. This type of problem is frequently a modelling error, your model of the environment in which your design is operating is flawed in that it does represent the real world (no real part would generate an input 0ns after the rising edge of a clock). One way to fix this type of error would be to generate the inputs on the falling edge of the clock. It's also possible that the input signal truly is asynchronous to your system clock. In this situation, hold time (and setup time) violations are inevitable, your design has to handle the async inputs properly with internal synchronizers but there is no way to get rid of the simulation detecting the violation since it really is occurring. One possible work around though would be to artificially add synchronization to the testbench. Kevin JenningsArticle: 132585
Eric Smith wrote: > Ray Andraka wrote: > >>Well, does this http://www.andraka.com/shortwave.htm demo project >>count? I did it as a demo back in early 2003. It worked surprisingly >>well considering there is no analog front end. > > > Very cool! Any plans to publish more details of the design? > > Best regards, > Eric I had been working on a chapter for it in my book. I gave up the book project because I was finding I couldn't dedicate enough time to it. I may eventually post more details on that page on my website. I kind of want to avoid putting the whole thing up there and giving college students a ready-made project.Article: 132586
"Symon" <symon_brewer@hotmail.com> wrote in message news:g1vebu$q48$1@aioe.org... > Hi Sam, > > Read the constraints guide. Also, Google this:- > multi cycle path > > NET "clock_en" TNM=FFS "clock_enable"; > TIMESPEC TS1 = FROM : clock_enable : TO : clock_enable : 8ns ; > > HTH., Syms. Thank, Symon. That did the trick. - SamArticle: 132587
Hi, I`m trying to make a temporal simulation ( Post place & route model ) of a FPGA designed in Xilinx 9.2i in Modelsim 6.0, but the Modelsim gives me an error of type Error - (vsim 3193), refered from a library called swifpli_mti.dll wich Modelsim doesn=B4t find. I can't get other Modelsim, and I was looking in the modelsim.ini file, changing any command that I found in Internet. This changes made the Modelsim execute the Behavorial model with a Xilinx core filters, but I didn't get the temporal simulation runs. How could I repared this? Thank you very muchArticle: 132588
On May 31, 10:16=A0am, <discussi...@fpga.usenet> wrote: > I have a jtag programmer with a 20pin idc connector. > Are these in general suitable for cplds/fpgas? > > Also, I have the following test program. The program > is supposed to switch on =A0a led when the input is hi. > Is this program ok? > > module modled(a1, b1); > input wire a1; > output wire b1; > > assign b1=3Da1; > > endmodule Yes, the jtag programmer is suitable for cplds/fpgas from a variety of manufacturers. JTAG is a standard and as such will be compatible. As for your program, try simulating and seeing what you get.Article: 132589
discussi...@fpga.usenet wrote: > I have a jtag programmer with a 20pin idc connector. > Are these in general suitable for cplds/fpgas? > > Also, I have the following test program. The program > is supposed to switch on a led when the input is hi. > Is this program ok? > > module modled(a1, b1); > input wire a1; > output wire b1; > > assign b1=a1; > > endmodule Keep in mind the 20 pin header may be rearranged from what your cpld/ fpga board expects; there is no header standard used throughout the industry. Also please make sure your JTAG voltages are compatible. Does your jtag programmer include your xilinx devices as a target? I end up just using the Xilinx USB Platform Cable to program my chips directly from the Xilinx utilities when I'm doing iterative design. A different JTAG programmer will probably need a generic, compatible file format. The Verilog module you included is one step in your journey. You may find a high on the input turns off the LED by driving the cathode high, depending on your board (active low logic). You still need to compile the code, assign pins, place & route the design, and generate a programming file. You have all that down? It should be covered pretty well in the documantation available to you. Welcome to the fun, - John_HArticle: 132590
How do I design a clock divider without using initial conditions. I designed once using initial values but they dont mean anything in synthesis. Thanks in advance for your helpArticle: 132591
On Jun 2, 4:10=A0pm, FP <FPGA.unkn...@gmail.com> wrote: > How do I design a clock divider without using initial conditions. With a reset signal. > I designed once using initial values but they dont mean anything in > synthesis. > If your targetted part has a specified power up state and the tools that you choose to use support initial values then initial values will work just fine. KJArticle: 132592
On Jun 2, 5:58 am, timinganalyzer <timinganaly...@gmail.com> wrote: > Hello All, > > The TimingAnalyzer can be used to quickly and easily draw timing > diagrams. > Signals, clocks, buses, delays, constraints, and states are easily > added > from the GUI. > > It can also be used to quickly do a timing analysis and check for > timing faults. Minimum, typical, and worst case analysis can be > performed. > Delays and constraints are easily specified and changed to see if > faster > clocks or slower parts can be used without any timing faults. > > There are 3 editions planned. The Free Edition(FE), the Standard > Edition(SE), > and the Professional Edition(PE). > > You can download the Free Edition now and read all about the > TimingAnalyzer at: > > www.timing-diagrams.com > > Comments and feedback are welcome at > > supp...@timing-diagrams.com Hey, it's back! It's good to see that this hasn't died. The commercial alternatives are WAAAAAY too expensive. -aArticle: 132593
Hi, I am a lover of Gentoo, I managed to do almost everything including my life and work in Gentoo. The only one thing left stuck me is the Celoxica DK which is intended to be working at RHEL, SUSE, or Debian based box. I did emerge rpm and dpkg, but still cannot get it working. If by chance anyone managed to get it working, could you please share with me? Thanks. SimonArticle: 132594
On Jun 2, 8:35=A0am, "Sam Worth" <no-re...@some.org> wrote: > "Symon" <symon_bre...@hotmail.com> wrote in message > > news:g1vebu$q48$1@aioe.org... > > > Hi Sam, > > > Read the constraints guide. Also, Google this:- > > multi cycle path > > > NET "clock_en" TNM=3DFFS "clock_enable"; > > TIMESPEC TS1 =3D FROM : clock_enable : TO : clock_enable : 8ns =A0; > > > HTH., Syms. > > Thank, Symon. That did the trick. > > - Sam Sam, here is an even simpler solution that works if you accumulate for many clock ticks and can sacrifice two or three clock ticks before you get the result. You just divide the long accumulator into 2, 3, or 4 parts, with a single carry flip-flop between (you thus pipeline the carry signal) Then, at the end, you use 1, 2, or 3 clock ticks to flush the carry through the accumulator. It costs you no additional hardware at all, (Virtex-5 has the pipeline flip-flop built-in) and it runs as fast as a short accumulator. You pay with the latency at the end. There is no free lunch... Peter AlfkeArticle: 132595
On Jun 2, 5:40 pm, Andy Peters <goo...@latke.net> wrote: > On Jun 2, 5:58 am, timinganalyzer <timinganaly...@gmail.com> wrote: > > > > > Hello All, > > > The TimingAnalyzer can be used to quickly and easily draw timing > > diagrams. > > Signals, clocks, buses, delays, constraints, and states are easily > > added > > from the GUI. > > > It can also be used to quickly do a timing analysis and check for > > timing faults. Minimum, typical, and worst case analysis can be > > performed. > > Delays and constraints are easily specified and changed to see if > > faster > > clocks or slower parts can be used without any timing faults. > > > There are 3 editions planned. The Free Edition(FE), the Standard > > Edition(SE), > > and the Professional Edition(PE). > > > You can download the Free Edition now and read all about the > > TimingAnalyzer at: > > >www.timing-diagrams.com > > > Comments and feedback are welcome at > > > supp...@timing-diagrams.com > > Hey, it's back! > > It's good to see that this hasn't died. The commercial alternatives > are WAAAAAY too expensive. > > -a Yes, it's alive and doing well, and yes the competition is expensive. The TimingAnalyzer will not be. I'm trying very hard to make it as easy as possible to use. Please feel free to request new features or suggest feature improvements. Regards, DanArticle: 132596
On 2008-06-03, Ambreen Ashfaq Afridi <amboafridi@gmail.com> wrote: > hi all, > Im working on a project in FPGAs called "network Traffic Manager" in > verilog implemented in virtex 4. Im using trimode ethernet MAC core in > it. Now i have to send a packet via ethernet to the other machine and > recalculate the checksum. For that i have to first calculate the > cheksum. Now the problem is that im a bit confused as to which > algorithm should I use to calculate the cheksum. I started to work on > TCP/IP checksum algo but now im totally confused b/w TCP/IP checksum > and CRC. So can anyone tell me which algo shud i use? Normally the ethernet MAC will take care of the CRC, so you will only need to care about the TCP/IP checksums. /AndreasArticle: 132597
On May 29, 7:56 am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 29 Mai, 07:59, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > > But, if you need 49 bits you lose a factor of two immediately. (The > fabric implementation grows only by a 2%, the DSP48 implementation by > 100%) I don't know that adders are a good comparison because they are pretty durn fast in an FPGA. The carry chain has been highly optimized and are still pretty good even at 48 bits. But if that is what people want from FPGAs, then I guess it shows that the dedicated logic route does not always pay large dividends. > It should be noted that in FPGAs both delay and area are dominated by > the routing ressources. Therefore mainly the granularity of the > routing should be optimized. I have never thought of "granularity" as a property of routing, but I see your point. I seem to recall that the ORCA devices claimed to facilitate routing of the four bit hunks their LUTS/FFs were arranged in. They didn't drop the 1x routing, but they had more of the 4x than other devices might have had. That was quite a while back when it was still AT&T. > No design has millions of gates of random logic. Large designs are > dominated by arithmetic function blocks. Therefore it is likely that > an FPGA with a granularity of 2 for example will have a much better > efficiency than current FPGAs. For random control logic half of the > LUTs would remain unused, but for datapathes the utilization would > approach 100% and the device coud save as much as 75% of the switches > and configuration bits. When you say "dominated", can you put that in definitive terms? The larger designs I have worked on were still very data path oriented with a lot of muxes (still not very efficient in generic LUT architectures) and pipeline delays. This was all IP type comms work, not RF/IF or mod/demod type stuff. > This is old knowledge for FPGA architecure folks, but there are two > strong arguments against it: > > 1.) > It is hard to quantify routing utilization, but the competitors > marketing will immediately target the lower LUT utilization as a > disadvantage. (But hey, if a LUT costs 75% less, who cares if I can > only use 80% of the LUTS? Especially if the clock frequency is > better?) Yes, that is in line with the quote I made above, "We sell you the routing and throw in the logic for free!", and that was in the days of XC4000 devices! It is pretty impressive in fact, just how dominating the routing is in an FPGA. The image in the chip editors is a pretty close approximation to the real spacial relations from what I have heard. If you zoom all the way out you will see very little of the logic, the chip is overwhelmingly routing. But like you point out, it is as much a marketing issue as anything. But even the technical people get wrapped up in the numbers game. It is more than once I have seen a post here about how "their" brand of chip is so much better because it has these features that let you do so much more in so little real estate... but in the end real estate is not on my list of FPGA critera, I only care about speed, power cost, etc. If feature X impacts those things, then I want to know that explicitly, not by inference. This trade off between routing and logic is similar in that no one wants to be known for only being 75% routable even if I can still fit my design in a cheaper chip because of it. > 2) > Granularity 1 FPGAs make use of the huge knowledge about ASIC EDA > algorithms. For higher granularities you need to redevelopemost of the > software toolflow from scratch. Does it really require new toolflows from *scratch*? I would expect that the current tools could be adopted. > There is a small FPGA vendor that has high speed global routing with > 10bit granularity. Maybe this is a start. The area savings are > marginal, as most of the switches are in local routing, but the speed > improvement for long connections is significant. That is interesting, especially how it improves the speed rather than density. RickArticle: 132598
hi all, Im working on a project in FPGAs called "network Traffic Manager" in verilog implemented in virtex 4. Im using trimode ethernet MAC core in it. Now i have to send a packet via ethernet to the other machine and recalculate the checksum. For that i have to first calculate the cheksum. Now the problem is that im a bit confused as to which algorithm should I use to calculate the cheksum. I started to work on TCP/IP checksum algo but now im totally confused b/w TCP/IP checksum and CRC. So can anyone tell me which algo shud i use? plz reply asap thank u Regards Ambreen AshfaqArticle: 132599
just for information: TCP/IP chksum calculates chksum on psuedo header which includes some fields from ip and some from TCP ip source add ip destination add tcp length tcp protocol number etc
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