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
Herbie <petemartin@ntlworld.com> wrote: > I know there is anecdotal evidence of people frying an FPGA by loading > illegal configuration patterns - eg when using evolutionary techniques, but > does anyone know of any published work on this? Something like that was done in: Ilija Hadzic, Sanjay K. Udani, and Jonathan M. Smith, "Hardware Viruses," in Field Programmable Logic 1999, Springer-Verlag, Edinburgh, UK (1999), pp. 291-300. -- T.RissaArticle: 42551
Does anyone know of an ABEL compiler that is available, free or otherwise, for use with Altera products; the MAX 7000 in particular. Xilinx and Lattice each have their ABEL tools, but Altera does not seem to support ABEL. Is there some third party option? If so where can I get it? Thanks in advance, BenArticle: 42552
"Stephen Henry" <s@s.com> wrote > I'm an Electrical Engineering Student enterring my final year and i > have to choose a project to do. I want to build and design a small and > simple computer system, with a fpga as its cpu (designed by me) -hopefully > getting to the stage where i can get it to output to a VGA device. With apologies to newsgroup regulars, please visit www.fpgacpu.org for helpful resources, and links, including a Circuit Cellar magazine series on just this subject (building a RISC CPU and system on a chip, including bitmapped video controller, and dev tools, in an XC4005). I think this can indeed be a managable senior project, but keep it simple! Jan Gray, Gray Research LLCArticle: 42553
BZZZT!
Wrong answer. The SpartanII most certainly is 5v tolerant. I believe the Vih max is 5.5v Using pull-ups is the way to get
outputs up to 5v, just make sure they are compatible with the rest of the bus. It has been awhile, but as I recall, the ISA bus
usually has someone pulling up on it anyway.
rickman wrote:
> Actually, you are violating the max Vih spec for these chips. Spartan
> II devices are not 5 volt tolerant and should not be used in this
> application. We are doing the same thing with the same chip and we are
> using a CoolRunner part as a large buffer chip to isolate the ISA bus
> from the Spartan II chip.
>
> If you are just designing an IO mapped, 8 bit peripheral, then you only
> need 8 data bits plus 10 address bits and 3 or so control lines. You
> can interface all this with three 245 chips. But as another poster
> said, you have to decode the address inside the FPGA to generate the
> enable to the 245 data buffer chip. If you are enabling it on just
> IORD, then you are responding when any IO device is being read and
> corrupting that data. This is why your PC won't boot.
>
> So add the decoding to the SpartanII, use a pullup on the enable to the
> data bus 245, enable the address and control line 245s at all times with
> the direction fixed to input from the bus and your design should start
> to work.
>
> Sean wrote:
> >
> > Hi everyone again.
> >
> > I think I solved my problem, but I did it by completely getting rid of
> > the transciever and simply putting 4.7k ohm pullup (to 5V) resistors
> > to the bus outputs. It seems to work fine, aside from some single
> > glitches on a few occasions. In any case it's much more reliable now
> > that it was. I'm not doing something foolish by using pullup
> > resistors on the bus though am I? It doesn't seem to cause any harm
> > or impede the operation of the PC in any way, at least visibly.
> >
> > Sean A Laughter <s2salaug@mail2.vcu.edu> wrote in message news:<Pine.SGI.4.33.0204241846190.308721-100000@neptune.vcu.edu>...
> > > Hi everyone.
> > >
> > > I'm interfacing a Spartan-II to an ISA/PC-104 bus. I have had no success
> > > with tying the Spartan directly to the bus, it is just not reliable and
> > > gives me sporadic values when reading from the Spartan. Since I have no
> > > trouble writing to the Spartan I'm assuming it has something to do with
> > > the 3.3V just basically not making it over the wires to the bus (because
> > > all my errors appear to be 1's that are being interpreted as lows).
> > >
> > > Anyway, to rectify this problem I'm attempting to use a 74HCT245
> > > transciever to pull the Spartan outputs to a full 5V. I'm tying the
> > > IOread signal to the direction pin of the transciever, but I can't get the
> > > PC to boot when the setup is attached to the ISA data bus.
> > >
> > > I've decided this is probably because the transciever needs to be in
> > > isolation mode at the appropriate time. However, I can't think of a way
> > > to do this during boot. It would be easy enough to control this once the
> > > Spartan is programmed because I'd have my ISA port code and I could just
> > > output a few signals to tell the 74HCT to go into isolation. This
> > > obviously isn't possible before the chip is programmed though, and so I'm
> > > stuck with a PC that won't boot with the spartan (via the transciever)
> > > attached to the data bus. The "enable" signal is active low. So when it
> > > is high the chip goes into isolation, which is what I would want at
> > > boot-up.
> > >
> > > Has anyone else used this chip in this fashion and can tell me how they
> > > solved this problem, or does anyone have any ideas on how to solve this
> > > problem? Thanks.
> > >
> > > Sean
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 42554
Oh yeah, for ISA IIRC, you need to spec a high current driver on several of the signals. 12 MA on data, and there were one or two
that need to drive 24mA. Since even 3.3v meets the high level spec for the ISA, I don't think pull-ups or lack thereof is the
problem, rather you are probably not providing enough drive on one or more signals. While I haven't interfaced SpartanII to the ISA
bus (don't have any computers left with those in them), I did do several 4KXLA designs that connected directly to the ISA bus several
years ago.
Ray Andraka wrote:
> BZZZT!
>
> Wrong answer. The SpartanII most certainly is 5v tolerant. I believe the Vih max is 5.5v Using pull-ups is the way to get
> outputs up to 5v, just make sure they are compatible with the rest of the bus. It has been awhile, but as I recall, the ISA bus
> usually has someone pulling up on it anyway.
>
> rickman wrote:
>
> > Actually, you are violating the max Vih spec for these chips. Spartan
> > II devices are not 5 volt tolerant and should not be used in this
> > application. We are doing the same thing with the same chip and we are
> > using a CoolRunner part as a large buffer chip to isolate the ISA bus
> > from the Spartan II chip.
> >
> > If you are just designing an IO mapped, 8 bit peripheral, then you only
> > need 8 data bits plus 10 address bits and 3 or so control lines. You
> > can interface all this with three 245 chips. But as another poster
> > said, you have to decode the address inside the FPGA to generate the
> > enable to the 245 data buffer chip. If you are enabling it on just
> > IORD, then you are responding when any IO device is being read and
> > corrupting that data. This is why your PC won't boot.
> >
> > So add the decoding to the SpartanII, use a pullup on the enable to the
> > data bus 245, enable the address and control line 245s at all times with
> > the direction fixed to input from the bus and your design should start
> > to work.
> >
> > Sean wrote:
> > >
> > > Hi everyone again.
> > >
> > > I think I solved my problem, but I did it by completely getting rid of
> > > the transciever and simply putting 4.7k ohm pullup (to 5V) resistors
> > > to the bus outputs. It seems to work fine, aside from some single
> > > glitches on a few occasions. In any case it's much more reliable now
> > > that it was. I'm not doing something foolish by using pullup
> > > resistors on the bus though am I? It doesn't seem to cause any harm
> > > or impede the operation of the PC in any way, at least visibly.
> > >
> > > Sean A Laughter <s2salaug@mail2.vcu.edu> wrote in message news:<Pine.SGI.4.33.0204241846190.308721-100000@neptune.vcu.edu>...
> > > > Hi everyone.
> > > >
> > > > I'm interfacing a Spartan-II to an ISA/PC-104 bus. I have had no success
> > > > with tying the Spartan directly to the bus, it is just not reliable and
> > > > gives me sporadic values when reading from the Spartan. Since I have no
> > > > trouble writing to the Spartan I'm assuming it has something to do with
> > > > the 3.3V just basically not making it over the wires to the bus (because
> > > > all my errors appear to be 1's that are being interpreted as lows).
> > > >
> > > > Anyway, to rectify this problem I'm attempting to use a 74HCT245
> > > > transciever to pull the Spartan outputs to a full 5V. I'm tying the
> > > > IOread signal to the direction pin of the transciever, but I can't get the
> > > > PC to boot when the setup is attached to the ISA data bus.
> > > >
> > > > I've decided this is probably because the transciever needs to be in
> > > > isolation mode at the appropriate time. However, I can't think of a way
> > > > to do this during boot. It would be easy enough to control this once the
> > > > Spartan is programmed because I'd have my ISA port code and I could just
> > > > output a few signals to tell the 74HCT to go into isolation. This
> > > > obviously isn't possible before the chip is programmed though, and so I'm
> > > > stuck with a PC that won't boot with the spartan (via the transciever)
> > > > attached to the data bus. The "enable" signal is active low. So when it
> > > > is high the chip goes into isolation, which is what I would want at
> > > > boot-up.
> > > >
> > > > Has anyone else used this chip in this fashion and can tell me how they
> > > > solved this problem, or does anyone have any ideas on how to solve this
> > > > problem? Thanks.
> > > >
> > > > Sean
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design URL http://www.arius.com
> > 4 King Ave 301-682-7772 Voice
> > Frederick, MD 21701-3110 301-682-7666 FAX
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 42555On 26 Apr 2002 20:23:28 -0700, Benjamin Heart <DAHZ@aol.com> wrote: > Does anyone know of an ABEL compiler that is available, free or > otherwise, for use with Altera products; the MAX 7000 in particular. > Xilinx and Lattice each have their ABEL tools, but Altera does not > seem to support ABEL. Is there some third party option? If so where > can I get it? I seem to recall having to use AHDL when using Altera parts. But if you use the Atmel ATF15xx family, which are largely compatible with the MAX7K series, you can use Atmel's ABEL tool. KellyArticle: 42556
"Michael Kleinkes" <michael.kleinkes@cryptovision.com> writes: > Please donīt misunderstand me, I only wonder why I donīt have the right to > get all the technical information to my product without any limitations. Same reason Intel doesn't give you a netlist for your Pentium IV. OK, not *exactly* the same reason, but close enough. The format of the bit stream is considered by the vendor to be a valuable trade secret, just as the netlist of the PIV is considered by Intel to be a valuable trade secret. Also, the vendor doesn't want to have to support people messing with the bit streams. Aside from the possibility of causing damage to the part, if they documented it they'd get inundated with tech support issues resulting from that. Lots of FPGA customers want the bit stream formats, but they're not likely to become available.Article: 42557
we got a problem in using a function repeatedly calling through a variable. any one is there to help in providing a sample code or an example. bhushanArticle: 42558
On 25 Apr 2002 18:47:09 -0700, hideout@usa.com (SECRET) wrote: >Hi, > >I noticed that Xilinx is claiming on their website that they have a >Vertex II PRO with a 3.125 Gbps Transceiver and up to 4 IBM PowerPC >Processors? Can you actually get silicon for this or is this just >Marketing BS? > >(do not e-mail me.. just post here) > >>Hideout< Priceless... Turn the headers on. See a line that says NNTP-Posting-Host: 66.35.226.228 Try a lookup... IP address: 66.35.226.228 Official name: ip66-35-226-228.altera.com oops! - BrianArticle: 42559
Hi everyone I am using synplicity 6.2.4 to synthesis my design, but it tell me that it can not recognize altera_implement_in_esb: @W: mul16.v(4): Unrecognized synthesis directive altera_implement_in_esb @W:"e:\ssy\nn\nn\nnarm\prim\indep\mul16\mul16.v":4:16:4:39 @W: alushell.v(1185): Unrecognized synthesis directive altera_implement_in_esb @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1185:16:1185:39 @W: alushell.v(1189): Unrecognized synthesis directive altera_implement_in_esb @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1189:16:1189:39 @W: alushell.v(1193): Unrecognized synthesis directive altera_implement_in_esb @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1193:16:1193:39 @W: alushell.v(1197): Unrecognized synthesis directive altera_implement_in_esb @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1197:16:1197:39 why?Article: 42560
Falk Brunner wrote: > > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag > news:3CC8BCEA.89FC0A7@yahoo.com... > > I am not clear about what the four clock resources are. Are you saying > > that there are only four BUFGs in the Spartan II and they go hand in > > hand with the DLLs? > > They do. Since the DLLS and BUFGs are very close together (with dedicated > routing between them) you have very good control over timing. > > > Four clocks with clock enables is not the clean approach I would like. > > I have a memory bus clock at 100 MHz, an MCU bus clock at 30.xxx MHz and > > four IO clocks at independant rates from 8 kHz to 60 MHz set according > > to the application which varies. Even if we use clock enables, that > > requires the reclocking of the data and the IO clocks would need to be > > distributed for the data reclocking. How would that be accommodated? > > Is there a way to use conventional routing and keep the skew low for a > > small number of clock inputs? > > How about this. Use a small asynchronous FIFO to synchronize all non-global > clock datas to your fastest clock. In this case, the clock on non-clock > lines must drive only a dozen clock inputs, which can be easyly constraint > to a column. Use > > NET mynet uselowskewlines; > > in the UCF to force the P&R to do so. > > -- > MfG > Falk Thanks Falk. Interesting that I got this advice from another user while the Xilinx FAE just tells me to read the data sheet. Can you tell me how/if this type of clock distribution will characterize the skew? I know that with the dedicated clock nets, Xilinx guarantees that the skew will not interfere with hold times on FF D inputs. Can the same guarantee be made with non-clock net routing? Somehow I was under the impression that the DLLs and the clock buffers could be operated independantly and that there were a total of 8 clock nets on the chip. Do the Virtex chips also only have four clock nets? It would be nice if there was a simple clear document explaining the differences in the two device families. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42561
Ray Andraka wrote: > > The DLLs work by delaying the clock input so that the delay, including the > delay through the clock distribution is equal to a period of the input > clock. The DLL has a state machine in it that dynamically selects the best > tap on a tapped delay line to accomplish that goal. > > The length of the tapped delay line determines the lowest frequency that can > be supported by the DLL. The 25 MHz minimum frequency spec ensures that the > delay line is long enough under any legal voltage/temperature/process > condition with some margin. Thanks for the post Ray. But I understand how the DLL works, at least at the top level of understanding. What I don't know is how all the clock resources in the chip play together. Somehow I had gotten the impression that the DLLs and the clock buffers could be used separately to let you route up to 8 clocks around on the chip. It would appear that I was wrong. I can certainly use the clock resync trick, especially for the slow clocks. But I am not clear how to keep the skew small enough on the peripheral clocks when you have, say 16 bit data to clock into the sync latch/fifo. But then I guess that might not be important if the data flow is done a certain way. I guess I am still concerned about data coming into the chip on my peripheral clocks. If an ADC only outputs data for say 2nS before and after the rising edge of the clock, will I be able to route the clock cleanly enough to the IOB FFs to meet the setup and hold times? Likewise one of the clocks may end up being the WRITE strobe from a processor. The clock route will need to be faster than the data path to prevent the loss of the hold time. Are there constriants to control this? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42562
I have been trying to get my hands on some pieces of XC2S150E-6FG456I for over a month. I am told that they will not be shipping until June and I need to get about four pieces for prototypes in a month. I can buy the commercial temp versions, but we need the industrial temp versions for this version of the board. I have tried working with distis and they keep saying that Xilinx won't give them parts until June no matter how much they beg. I have contacted the rep and they keep talking about placing an order so that it can be expedited. But what is the point of placing an order if I can't get delivery when I need it? Anyone know how to get your hands on a small number of ES chips prior to the official release? I was able to get some chips from the Coolrunner product manager under these same conditions awhile back. But I don't have a way to contact the SpartanIIE product manager. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42563
I've got a device that "can't be doing that" and suspect the bank of LEDs. I drive them with OBUF_S_24s as they take about 15mA. This breaks the rules in the "Max number of simultaneous switching outputs" table. If I use OBUF_S_12s say, I would be ok for switching rules but would the output buffers then drop whatever and reduce the output current or would they drive the same and just take a ns or so longer to switch ? That is does the OBUF drive current really affect DC drive capability or just switching speed ? There are no V/I curves. JonArticle: 42564
It is a boolean attribute, not a directive - You have to give it a value. /* synthesis altera_implement_in_esb=1 */ ssy wrote: > Hi everyone > > I am using synplicity 6.2.4 to synthesis my design, but it tell me > that it can not recognize altera_implement_in_esb: > > > @W: mul16.v(4): Unrecognized synthesis directive > altera_implement_in_esb > @W:"e:\ssy\nn\nn\nnarm\prim\indep\mul16\mul16.v":4:16:4:39 > @W: alushell.v(1185): Unrecognized synthesis directive > altera_implement_in_esb > @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1185:16:1185:39 > @W: alushell.v(1189): Unrecognized synthesis directive > altera_implement_in_esb > @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1189:16:1189:39 > @W: alushell.v(1193): Unrecognized synthesis directive > altera_implement_in_esb > @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1193:16:1193:39 > @W: alushell.v(1197): Unrecognized synthesis directive > altera_implement_in_esb > @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1197:16:1197:39 > > > why? >Article: 42565
>Thanks for the post Ray. But I understand how the DLL works, at least >at the top level of understanding. What I don't know is how all the >clock resources in the chip play together. Somehow I had gotten the >impression that the DLLs and the clock buffers could be used separately >to let you route up to 8 clocks around on the chip. It would appear >that I was wrong. The data sheets usually describe the clock distribution resources. I'm sure it's in there now that you know what to look for. Whenever I start working with a chip, I usually spend a lot of time with the FPGA Editor (XACT?) learning the details of the special routing resources. That involves iterations of reading the data sheets, making test cases, seeing what really results... There are occasional "Ahh. That's what that section was telling me." Maybe I work/think at too low a level and should just push the big green button, but I always end up pushing some timing limit. I'm not sure how to do that if I don't know what I want the tools to produce. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42566
The best way we have to deal with the glitching (without giving up the fast
carry chains at least) is to deeply pipeline a design. Pipelining at nearly
every LUT keeps the glitch propagation to a minimum. It would be interesting
to see a comparison of power for a deeply pipelined over clocked design for
something running at a lower rate but with many levels of combinatorial
logic.
As for the routing contributing to power, we have definitely seen an effect.
Floorplanning seems to consistently decrease power by 20% or more over the
same design automatically placed.
We recently did our first design that needed fans on the FPGAs (we've got a
couple of designs with heatsinks). I had a picture of the board with pentium
style coolers on the V2000E's with my exhibit at FCCM earlier this week. In
that case, each FPGA is dissipating 14w (measured).
Austin Lesea wrote:
> Tim,
>
> I wondered why I was writing this note about power... (actually I am).
>
> In Virtex II and Virtex II Pro we see the beginnings of something that we
> need to address with design techniques, tools, and automated software
> awareness. If you can't do it manually, then there is no way to automate
> it. Techniques to reduce the 'glitch' power Steve mentions includes
> reducing the amout of interconnect attached to a toggling LUT node (ie
> register in the CLB), or registering ahead of the inputs to reduce the
> skew int he arrival times at the LUT to reduce gratuitous toggling.
>
> I imagine someday a button labled "optimize for power" in the FPGA
> synthesis flow, just as there are area vs speed buttons today.
>
> Right now, there is no "hot spot" as the silicon conducts the heat
> sufficiently well. The hot spots Steve is referring to are spots which a
> perhaps a few degrees C warmer than the surrounding areas. Easily imaged
> with IR sensors.
>
> Steve is right, and when he says "could be" he is just teasing. We are
> designing 'future' FPGAs already.
>
> Austin
>
> Tim wrote:
>
> > Austin
> >
> > To help in the hunt, here is the reference to the eetimes
> > news article:
> >
> > http://www.eetimes.com/semi/news/OEG20020228S0050
> >
> > Quoting from eetimes:
> >
> > Despite this reluctance to tackle the issue head-on, power consumption
> > could soon be at the top of the to-do list in the near future,
> > especially if programmable logic device (PLD) makers are serious
> > about winning sockets in power-sensitive consumer electronics
> > applications, said Xilinx's Trimberger.
> >
> > Xilinx has already taken the first steps to raise the awareness of
> > power issues by disclosing a study on the hot spots in its latest
> > Virtex 2 architecture. In the paper, the company showed that 60
> > percent of the power consumption in the Virtex 2 family is from
> > routing while logic and clocking account for 16 and 14 percent,
> > respectively.
> >
> > Additionally, Xilinx found that the cluster of LUTs, flip-flops and
> > other circuitry that make up its configurable-logic blocks take up
> > 5.9 microwatts per MHz for a typical design. But this is just for
> > "typical" designs; actual power consumption within the configurable
> > logic blocks (CLBs) can change wildly depending on the switching
> > activity. This can occur frequently in synchronous circuits, where
> > the inputs to the LUTs come in at different times during the same
> > clock cycle. This "glitching" effect could contribute up to 70 percent
> > of the power dissipation in a CMOS circuit, whether it's an ASIC or
> > FPGA.
> >
> > <end quote>
> >
> > I guess you feel an application note coming on :-)
> >
> > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> > news:3CC42242.B251D66F@xilinx.com...
> > > Tim,
> > >
> > > I don't recall the article, I'll go look...
> > >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 42567>It all depends on what speed you are running. In my experience of customer >designs that are running fairly slow (<60MHz) they have had no problems >literally filling the devices to the gills. >As you increase the usage, you end up with the Mapper merging un-related logic, >and the side effect of this is of course performance. I can't figure out what that means, but it seems interesting, maybe even important. Is there any basic reason why putting unrelated logic in otherwise empty slots is going to hurt performance? Or is that just a handy rule of thumb to indicate that the routing will have to work a bit harder? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42568
Say I have 2 parallel filters. I feed a multiplixer with the two filters'output. The output should be frist derived from a filter F1 and then F2. Hence whenever the outputs of the two filters are valid, Sel input of the multplixer should be at zero level, and then transit between 1 and zero. as you see i have to put the Mux sel, at a certain instant T0, in a certain state. In order to do so, i compute the latency of the two filters to deduce the initial state of my Sel signal. if their latency are odd, the state of the toogle flip flop is 0, otherwise 1 Is it appropriate? ant comments -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 42569
Hal Murray wrote: > > >Thanks for the post Ray. But I understand how the DLL works, at least > >at the top level of understanding. What I don't know is how all the > >clock resources in the chip play together. Somehow I had gotten the > >impression that the DLLs and the clock buffers could be used separately > >to let you route up to 8 clocks around on the chip. It would appear > >that I was wrong. > > The data sheets usually describe the clock distribution resources. > I'm sure it's in there now that you know what to look for. > > Whenever I start working with a chip, I usually spend a lot of time > with the FPGA Editor (XACT?) learning the details of the special > routing resources. That involves iterations of reading the data > sheets, making test cases, seeing what really results... There > are occasional "Ahh. That's what that section was telling me." > > Maybe I work/think at too low a level and should just push the big > green button, but I always end up pushing some timing limit. I'm > not sure how to do that if I don't know what I want the tools to > produce. Yes, that is what I always end up doing. But it takes a lot of time and if the documentation was more clear, this interaction with the graphic tools would not be required to learn the architechture. However you always have the need to learn what the HDL tools are doing with your design. I have never seen a tool that did not need a babysitter. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42570
Peter Alfke wrote > We at Xilinx are very interested in any constructive suggestions how we can > make our documentation, especially in my case the data sheet, clearer and > easier to use. One splendid feature of Xilinx data sheets of yore, seemingly now out of favor, was the "differences from previous generation" page. Taking a leaf out of consumer electronics user guides, perhaps this should be "even if you (think) you are an expert, read this" :) Another great feature which has evaporated is the routing/PIP diagram, which looked like an extract from XACT. Much easier to mull over than FPGA_editor, especially for those of us condemned to the low-level stuff.Article: 42571
In article <1019954357.24255.0.nnrp-01.9e9832fa@news.demon.co.uk>, Tim <tim@rockylogic.com.nooospam.com> wrote: >Another great feature which has evaporated is the routing/PIP diagram, >which looked like an extract from XACT. Much easier to mull over >than FPGA_editor, especially for those of us condemned to the >low-level stuff. Agreed. I LOVE that diagram on the XC4K datasheets. I'd love to see the equivelent for Virtex/Virtex II family parts. It would also be a good "WHoah, there is a lot of routing" picture. :) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42572
Tim wrote > One splendid feature of Xilinx data sheets of yore, seemingly now > out of favor, was the "differences from previous generation" page. > Taking a leaf out of consumer electronics user guides, perhaps this > should be "even if you (think) you are an expert, read this" :) Thanks, that was my idea, and my doing. But for almost ten years, nobody (nobody!) ever expressed any appreciation for it. Not Marketing, not Sales, and not even the users. The classical question "who cares?" Lots of good ideas die when there is no feedback... Peter AlfkeArticle: 42573
Peter Alfke wrote: > > Tim wrote > > > One splendid feature of Xilinx data sheets of yore, seemingly now > > out of favor, was the "differences from previous generation" page. > > Taking a leaf out of consumer electronics user guides, perhaps this > > should be "even if you (think) you are an expert, read this" :) > > Thanks, that was my idea, and my doing. > But for almost ten years, nobody (nobody!) ever expressed any appreciation for > it. > Not Marketing, not Sales, and not even the users. The classical question "who > cares?" > Lots of good ideas die when there is no feedback... You didn't talk to the right users :-) And add a vote for 'difference from previous release' - US suppliers often skip this, but European and Asian are better, but not perfect. eg Philips used to have a bold arrow, for Delta tag, in their older data sheets. -jgArticle: 42574
Nicholas Weaver wrote: > I > > Agreed. I LOVE that diagram on the XC4K datasheets. I'd love to see > the equivelent for Virtex/Virtex II family parts. > > It would also be a good "WHoah, there is a lot of routing" picture. > :) > These drawings (and others) were killed because we did not want to call undue attention to the internal complexity of the FPGA structure. Especially when the main competitor brags about his no-brainer automatic "push-button" design. :-( There is a fine line between explaining all the details and exotic capabilities, and scaring potential customers off. Unfortunately, the documentation cannot be censored or easily be adapted to the intelligence ( or level of friendliness, patience, and dedication ) of the user. Peter Alfke, Xilinx Applications
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