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
"Apolonio B. Sanches" <paulsan@asti.dost.gov.ph> wrote: >To all >I'm making a survey regarding the limitations in features of PLCs. I am assuming you are talking about Programable Logic Controllers typically used in industrial controls >I would like to have your comments on what improvements or added features >should be added or improved in today PLC. The line betweeen PLCs and Personal Computers has become very grey in the past couple of years. PLCs have had more complex algorithms added to them since the '80s. The capabilities of PLCs have approached that of the PC, but the PC is more suitable for data aquitsition and control (something industrial engineers and managers want). I see PLCs going the way of the panel-box-full of relays. A PC with a Controller Area Network doing the work of a PLC as well as data aquisition will be the standard in the future. >What are the important things you look for in choosing a PLCs? I look for a PLC that will match the job at hand, reliabilty and if necessary, expandabilty. Lisa Jones Fit by Design. . .Article: 5826
Anybody have thoughts/recommendations on the following tools for FPGA/ASIC design: 1) VeriBest (currently reselling Synopsys FPGA Express) 2) Synplicity 3) Exemplar 4) Synario 5) Viewlogic Thanks!Article: 5827
Peter Alfke (peter@xilinx.com) wrote:
> In article <L3ZHANG.18.3324A6E7@ELECOM2.watstar.uwaterloo.ca>,
> L3ZHANG@ELECOM2.watstar.uwaterloo.ca (Louis Zhang) wrote:
>
>
> > Unfortunately, unlike the discrete RAM and RAM cell in ASIC, the RAM cell in
> > Xilinx 4000 has address and data setup/hold time requirements.
>
> Whenever I read "hold time" my blood pressure goes up 10 mm.
> The XC4000E data sheet lists hold time as 0, i.e. ZERO.
> So, don't worry about hold time. And EVERY clocked device has a set-up time.
Unfortunately, the prototype board (BORG board) that Louis (and myself -- in
the same class) is required to use in his project contains (interconnected
to each other and interfaced to a PC via an ISA card connected to one of
the 4002 chips):
2 x 4002APC-6
2 x 4003APC-6
At least that is what we were told. So the specs of the 4000E series
unfortunately do not apply. :)
Unforunately again, our lab group is having a real painful time of trying
to get our design to work on the BORG board. It simulates perfectly in
Compass-DA (both the VHDL synthesized and backannotated versions), but
does not operate AT all on the hardware... We are going to talk to the
lab tech for the course tomorrow. But I am rambling as usual :) Sorry.
I shall go to bed now. G'night.
--
Gavin J. Hurlbut gjhurlbu@beirdo.uplink.on.ca
4B Electrical Engineering ---------------------------------
University of Waterloo School sucks.
My Homepage: http://amprgate.uwaterloo.ca/~gjhurlbu/
Article: 5828
David Gesswein wrote:
>
> Has anybody found any documentation on using multiple clocks in a xilinx
> 4000/5200 part? The question I have is how to transfer signals between the two
> clock domains. Can you use a low skew external clock generator and the internal
> clock distribution including the two global clock buffers skew will be small
> enough that the hold time when a register feeds a register will be met or
> do I have to treat the clocks as asynchronous or use different edges or
> other methods to ensure that the signal will be transfered reliably?
>
> The reason for the two clocks is that most of the design should run at a slower
> clock but a little bit needs to run faster so using the clock enable to
> simulate the slower clock seems excessive.
>
> I talked to the hotline but they didn't have any application information on the
> use of multiple clocks.
>
>
This all relates to the clock skew spec. Lets see, if you look in the
book it's ...
hmmm .. it isn't there. But there is a FF hold spec of 0 ns. If we
assume a min delay for any clock to input path of 0 ns, that would imply
a clock skew of 0.000 ns. Note the fine precision of my calculation. So
how do we ge skew of 0.000 ns?
In my experience it is impossible to deliver 2 matched clocks to a chip
with a guaranteed skew of less than .5 ns. That skew would violate the
skew spec of 0.000 ns, but lets assume they are 'identical', (because
you measure them).
The pad to clock delay will be 0 ns to Tcin, where Tcin is the value
found by using 'xdelay syntax' FROM:PADS(clk_in):TO:FFS(*). Typical
delays will be 5-10 ns. If you assume max delay for one clock and min
delay for the another, the clock skew could be 5-10 ns. This is of
course greater than the spec of 0.000 ns so it won't work.
However the value is dependent on clock loading and the delays will
track to some degree. In general they will be within 1 or two ns. So
lets assume they were identical because you adjusted the number of clock
loads to make them match. If you apply the "not-guaranteed" tracking
ratio of 70% you will have a skew of .3*8 ns=2.4 ns. This is greater
than the spec time of 0.000 ns, so we are still illegal.
But lets assume full tracking because you actually XOR the two clocks
together on the FPGA and adjust the phase of one of the clocks with an
off chip PLL. Now our skew is say 0.1ns. Maybe this will work? Nope it
still violate the spec of 0.000 ns.
So lets abandon the whole concept of two clocks and just see if we can
just clock data from one register to another with the same clock.
Typically, Xdelay spews out the following skew:
"
Source clock net : "mem0_clk" (Rising edge)
From: Blk em0_data<7>_p CLOCK to P121.I1 : 2.8ns (
2.8ns)
Thru: Net mem0_data<7>_1 to CLB_R11C13.F4 : 5.7ns (
8.5ns)
Thru: Blk _write_ptrs4_xor<6> to CLB_R11C13.X : 2.0ns (
10.5ns)
Thru: Net _write_ptrs4_xor<6> to CLB_R10C13.F3 : 1.4ns (
11.9ns)
Thru: Blk ip_write_ptrs4_equ1 to CLB_R10C13.X : 2.0ns (
13.9ns)
Thru: Net ip_write_ptrs4_equ1 to CLB_R13C12.F3 : 1.4ns (
15.3ns)
Thru: Blk ip_write_ptrs4_equ to CLB_R13C12.X : 2.0ns (
17.3ns)
Thru: Net ip_write_ptrs4_equ to CLB_R14C12.F4 : 1.1ns (
18.4ns)
Thru: Blk ip_write_ptrs4_lop to CLB_R14C12.X : 2.0ns (
20.4ns)
Thru: Net ip_write_ptrs4_lop to CLB_R12C11.F1 : 1.7ns (
22.1ns)
Thru: Blk ip_write_ptrs4_i1 to CLB_R12C11.X : 2.0ns (
24.1ns)
Thru: Net ip_write_ptrs4_i1_1 to CLB_R11C20.F2 : 3.2ns (
27.3ns)
Thru: Blk sram0_write to CLB_R11C20.X : 2.0ns (
29.3ns)
Thru: Net sram0_write to CLB_R1C20.G1 : 2.3ns (
31.6ns)
To: FF Setup (D), Blk mem0_ose : 3.0ns (
34.6ns)
Target FFX drives output net "mem0_sram"
Dest clock net : "mem0_clk" (Rising edge)
Clock delay to Source clock pin : 1.7 ns
Clock delay to Dest clock pin : 1.5 ns
Clock net "mem0_clk", delta clock delay [skew] : -0.3 ns
"
Well Xdelay might not be too good on math, but lets assume the skew
really is -0.3 ns.
Of course -0.3 ns violates the derived legal spec of 0.000 ns. I guess
we have to conclude that we can't clock from one register to another
even using the same clock.
OK, what the hell. If Xilinx can cheat its own spec, I guess you can.
But I might try the following instead:
Assume a 2x clock ratio. Advance the slow clock by say 5ns from the fast
clock. This ought to cover any distribution skew. You can legally
clock from the slow clock edge to the fast clock, and visa versa. Just
avoid latching slow data on the odd fast clock cycles.
Cyc : 0 : 1 : 2 : 3 : 4 :
CLK1
______/-----\_____/-----\_____/-----\_____/-----\_____/-----\_____/-----\
CLK2
___/-----------\___________/-----------\___________/-----------\___________/
C1data
-X=======================X=======================X=======================X
C2data
-===X===========X===========X===========X===========X===========X===========X
|<>| 5ns
|<------------>| Tsu_c2_c1
|<------>| Tsu_c1_c2
Hope this helps.
-
Brad
Article: 5829
Brad Taylor wrote:
> Typically, Xdelay spews out the following skew:
>
> "
> Source clock net : "mem0_clk" (Rising edge)
> From: Blk em0_data<7>_p CLOCK to P121.I1 : 2.8ns (
> 2.8ns)
> Thru: Net mem0_data<7>_1 to CLB_R11C13.F4 : 5.7ns (
> 8.5ns)
> Thru: Blk _write_ptrs4_xor<6> to CLB_R11C13.X : 2.0ns (
> 10.5ns)
> Thru: Net _write_ptrs4_xor<6> to CLB_R10C13.F3 : 1.4ns (
> 11.9ns)
> Thru: Blk ip_write_ptrs4_equ1 to CLB_R10C13.X : 2.0ns (
> 13.9ns)
> Thru: Net ip_write_ptrs4_equ1 to CLB_R13C12.F3 : 1.4ns (
> 15.3ns)
> Thru: Blk ip_write_ptrs4_equ to CLB_R13C12.X : 2.0ns (
> 17.3ns)
> Thru: Net ip_write_ptrs4_equ to CLB_R14C12.F4 : 1.1ns (
> 18.4ns)
> Thru: Blk ip_write_ptrs4_lop to CLB_R14C12.X : 2.0ns (
> 20.4ns)
> Thru: Net ip_write_ptrs4_lop to CLB_R12C11.F1 : 1.7ns (
> 22.1ns)
> Thru: Blk ip_write_ptrs4_i1 to CLB_R12C11.X : 2.0ns (
> 24.1ns)
> Thru: Net ip_write_ptrs4_i1_1 to CLB_R11C20.F2 : 3.2ns (
> 27.3ns)
> Thru: Blk sram0_write to CLB_R11C20.X : 2.0ns (
> 29.3ns)
> Thru: Net sram0_write to CLB_R1C20.G1 : 2.3ns (
> 31.6ns)
> To: FF Setup (D), Blk mem0_ose : 3.0ns (
> 34.6ns)
> Target FFX drives output net "mem0_sram"
> Dest clock net : "mem0_clk" (Rising edge)
> Clock delay to Source clock pin : 1.7 ns
> Clock delay to Dest clock pin : 1.5 ns
> Clock net "mem0_clk", delta clock delay [skew] : -0.3 ns
> ^^^^
> "
>
> Well Xdelay might not be too good on math, but lets assume the skew
> really is -0.3 ns.
> Of course -0.3 ns violates the derived legal spec of 0.000 ns.
^^^^^
Well, you probably noticed, this case is totally legal as the source
clock is delayed from the destination. So here is an example of the
other direction. In this case the source will
change .2ns before the destination clock arrives. Also notice that
XDelay assume 100% tracking.
It should also be noted these FPGAs actually work fine. I'm just trying
to point out that Xdelay
makes assumptions that we (as users) must assume to be illegal.
Logical Path Delay
Cumulative
------------ -----
----------
Source clock net : "mem0_clk" (Rising edge)
From: Blk nw_ctr<2> CLOCK to CLB_R3C14.XQ : 2.8ns (
2.8ns)
Thru: Net nw_ctr<2> to CLB_R5C7.F3 : 3.7ns (
6.5ns)
Thru: Blk wmem_add<2> to CLB_R5C7.X : 2.0ns (
8.5ns)
Thru: Net wmem_add<2> to CLB_R4C8.F3 : 4.4ns (
12.9ns)
Thru: Blk wmem<4> to CLB_R4C8.X : 2.0ns (
14.9ns)
Thru: Net wmem<4> to CLB_R4C5.F2 : 1.5ns (
16.4ns)
Thru: Blk mem1_wdata<4> to CLB_R4C5.X : 4.3ns (
20.7ns)
Thru: Net mem1_wdata<4> to P39.O : 5.0ns (
25.7ns)
To: FF Setup (D), Blk mem1_data<4>_p : 4.6ns (
30.3ns)
Target FF drives PAD "mem1_data<4>_p" (P39)
Dest clock net : "mem0_clk" (Rising edge)
Clock delay to Source clock pin : 1.5 ns
Clock delay to Dest clock pin : 1.7 ns
Clock net "mem0_clk", delta clock delay [skew] : 0.2 ns
Sorry for the confusion,
-
Brad
Article: 5830I don't know about the rest of you guys but personally, I hate being confined to a single source for any part. It causes too much turbulence, upset, stress, disturbance etc. in my life All of a sudden, the sole source decides to - raise the price - discontinue the part - "improve" the part by supplying only a new, smaller higher speed version that causes more noise, glitches ground bounce and all of those other things that higher speed does - move to anothe fab that doesn't work any more All of these things cause my chain to be pulled and I have to drop whatever I'm doing - that my boss thinks is a good thing - and address the problem created by these changes. These changes are a LOT less severe if there is another supplier that hasn't done them. That's some of the reasons that I, personally HATE being confined to a single source. Wouldn't you think that with many suppliers now rushing into the FPGA field, one or two of them that are not yet market dominant would see the marketing advantage of forming alliances with others and do more second sourcing? Hint Hint What do you think? ... Garnet -- return address is fake to try to reduce junk mail if you wish to send e-mail to me please send to cgbi@ionsys.comArticle: 5831
Dirk Brandis <brandis@dlcc.com> wrote: >Anybody have thoughts/recommendations on the following tools for >FPGA/ASIC design: >1) VeriBest (currently reselling Synopsys FPGA Express) >2) Synplicity >3) Exemplar >4) Synario >5) Viewlogic >Thanks! I have ben using Synario for awhile now and I like it pretty well. I was part of the beta test program for a new FPGA design system by Orcad called Express. I believe that it is due to be released this month. It features schematic entry and VHDL support for all of the major players in the FPGA world. You would still need the place and route compiler for the FPGA of your choice as Express is just a fornt-end. I donlt know what their final decision will be on pricing, but this package deserves a check-out.Article: 5832
Hari Shankar wrote: > > Is it possible to purchase a development board with multiple XILINX 4000 > series FPGAs so that large designs can be accomodated? If so, can I > have the address/phone# of the company? > > Thanks in advance, > > Hari Shankar Try the PCI Pamette board. It's got a reconfigurable PCI interface and 4 4010E for user applications (can go to 4 4020E I guess). It's got drivers for Digital unix and Windows NT. I find it great. You can find more information about it at: http://www.research.digital.com/SRC/pamette/ LaurentArticle: 5833
Some of the math here is getting out of hand. A mathematical "proof" that one cannot even build a shift register with a common clock just shows that the assumptions are wrong, since such designs are working by the millions. Some of these subtleties are impossible to capture in a data sheet. Any absolute min delay can be quite short, but it cannot coexist with a max delay....etc. Now to the original question: Skew between two clocks. XC4000 ( and its brothers ) first: Each clock is run to the center of the chip and drives its own horizontal "spine". The clock tree then "grows" vertical clock lines wherever they are needed ( Clock power thus depends on the number of vertical CLB columns that are clocked, remember that for low-power applications ) "Normal" clock skew between different destinations of the same clock is within 2 ns, which has created the data sheet statement that clock skew is always less than the sum of set-up time, clock-to-Q, plus shortest routing, thus guarateeing that there is no on-chip hold-time issue or potential race condition. If the part is ultra-fast, cold and with high Vcc, then the clock skew is also less. So: Don't worry, be happy. "Normal" clock skew between two clocks is similarily very small. "Normal" means that the clocks are loaded in a non-extreme way. We are right now measuring "abnormal" clock loading conditions: One clock loaded with every branch and every flip-flop on the chip, the other one driving only one single flip-flop in the most favorable position. And of course testing this for rising as well as falling-edge conditions. I will report on this later. XC5200 is optimized for cost, not for speed and fancy features. Its clock has more skew since the four clocks each drive a spine along their respective edge, then drive into the device. For any single clock, the above-mentioned guarantee still holds, but don't apply it to the relationship between two clocks. In XC5200 you might, at worst, have the case where two close-by flip flops see significant clock skew if they are clocked from separate clock inputs. The skew might be as much as 5 ns worst case. Note that this only applies to skew between different clocks. A single-clock skew of such magnitude could only be between opposite corners of the chip, and the routing delays would then inherently get rid of all race-condition problems. It looks like I am signing up for an app note on this subject. But I don't want to belabor the difference between 0 ns, 0.0 ns, 0.00 ns and 0.000 ns. Peter Alfke, Xilinx ApplicationsArticle: 5834
>>...Could it be that the consortium >>members want no challenges from those who are not big enough to do hardwired >>gate arrays? >In fairness, while complex, hard-to-meet standards certainly do serve the >interests of large, established companies by making it difficult for little >startups to compete, one need not assume actual malice. There is always a >tradeoff between performance and easy implementation, and big companies can >cope with implementation difficulties relatively easily, so naturally their >design ideas are biased strongly toward maximum performance. Yes. We are now in an era where standards (and I am referring to actual, not ad hoc, standards) are being designed with the assumption that ASICs, and other technologies such as connectors, will be developed specifically for the standard. PCI is definitely one of them. USB, Fire-wire and SSA are also good examples. The standards specify the connector, the electricals, and several layers of protocol, and often a single ASIC can be built to handle the electricals and some of the layers. You could do it with PALs and PGAs, but you probably won't be competitive. An advantage of this, is that we all have longer to prepare for the standard's emergence (if we can guess which ones will succeed and when)-- because it takes so long to work out all the details. And yes, the technology will have higher performance. Consider that SCSI-1 was drafted at a time when it was assumed that all SCSI interface circuits would be built with 74XX TTL - there's a standard which has turned out to have very long legs. GregArticle: 5835
In article <33302EEA.6907@xilinx.com>, peter@xilinx.com wrote: > Some of the math here is getting out of hand. Please disregard the previous "reply". I accidentally posted it here, it was meant to go with a different thread, discussing issues with multiple clocks in Xilinx FPGAs. One wrong click... :-( Again, sorry for the confusion Peter AlfkeArticle: 5836
Some of the math here is getting out of hand. A mathematical "proof" that one cannot even build a shift register with a common clock just shows that the assumptions are wrong, since such designs are working by the millions. Some of these subtleties are impossible to capture in a data sheet. Any absolute min delay can be quite short, but it cannot coexist with a max delay....etc. Now to the original question: Skew between two clocks. XC4000 ( and its brothers ) first: Each clock is run to the center of the chip and drives its own horizontal "spine". The clock tree then "grows" vertical clock lines wherever they are needed ( Clock power thus depends on the number of vertical CLB columns that are clocked, remember that for low-power applications ) "Normal" clock skew between different destinations of the same clock is within 2 ns, which has created the data sheet statement that clock skew is always less than the sum of shortest set-up time, shortest clock-to-Q, plus shortest routing, thus guarateeing that there is no on-chip hold-time issue or potential race condition. If the part is ultra-fast, cold and with high Vcc, then the clock skew is also less. So: Don't worry, be happy. "Normal" clock skew between two clocks is similarily very small. "Normal" means that the clocks are loaded in a non-extreme way. We are right now measuring "abnormal" clock loading conditions: One clock loaded with every branch and every flip-flop on the chip, the other one driving only one single flip-flop in the most favorable position. And of course testing this for rising as well as falling-edge conditions. I will report on this later. XC5200 is optimized for cost, not for speed and fancy features. Its clock has more skew since the four clocks each drive a spine along their respective edge, then drive into the device. For any single clock, the above-mentioned guarantee still holds, but don't apply it to the relationship between two clocks. In XC5200 you might, at worst, have the case where two close-by flip flops see significant clock skew if they are clocked from separate clock inputs. The skew might be as much as 5 ns worst case. Note that this only applies to skew between different clocks. A single-clock skew of such magnitude could only be between opposite corners of the chip, and the routing delays would then inherently get rid of all race-condition problems. It looks like I am signing up for an app note on this subject. But I don't want to belabor the difference between 0 ns, 0.0 ns, 0.00 ns and 0.000 ns. Peter Alfke, Xilinx ApplicationsArticle: 5837
In article <5go10m$3c4@maggie.ionsys.com>, hakk@cent.com (Garnet Brace) wrote: > I don't know about the rest of you guys but personally, I hate > being confined to a single source for any part. The days of second-sourcing state-of-the-art devices are over. The major manufacturers see no benefit in it. When this industry was young and small, and when the military demanded second sourcing, it was common practice to ordain a second source. The manufacturers even then realized that it was somewhat perverse to give away the crown jewels to a competitor, but they did it because it was supposed to grow the market acceptance. The good aspects overcompensated the bad ones. Now that most of the manufacturers are reasonably big and considered viable even by their customers, the negative aspects of putting a competitor into the saddle outweigh the marginal positive ones. If you don't believe me, read Andy Grove. He says the same thing. Intel needed AMD as a second source when Intel was a small company and many designers refused to design in a single-sourced vital part. Times have changed. Everybody knows that Intel can and will produce, and designers have learned to cope with the less pleasant commercial aspects of single-sourcing. And AMD et.al. second sourced or copied or re-engineered or re-invented the Intel microprocessors anyhow, although with lots of work and pain and lawyers' fees. A single source must and will use multiple fab lines ( to protect against accidents ) and must be forthcoming in price reductions. I think we in the FPGA world have done that, and will continue to do it, even without direct pressure from a second source. Lowering prices and improving performance is in our selfish interest, because it allows us to grow into an almost limitless market. We don't need a second source to push us, we are pulled by the market opportunities. Much nicer feeling. Peter Alfke, Xilinx ApplicationssArticle: 5838
In article <5gn6gs$5sp@camel2.mindspring.com>
jpjcet@mindspring.com "Paul Jones" writes:
> The line betweeen PLCs and Personal Computers has become very grey in
> the past couple of years. PLCs have had more complex algorithms added
> to them since the '80s. The capabilities of PLCs have approached that
> of the PC, but the PC is more suitable for data aquitsition and
> control (something industrial engineers and managers want).
Whilst I might agree that the PC, suitably protected from the industrial
nastiesand given the right interfaces, makes a very good data aquisition
device, I would not countenance it's use for control of anything but
measurement valves or relays. The control of "real machinery" or other
Safety Related control applications is better left to PLC's and computer
control systems that are designed specifically for the environment they
will work in. Most PC's, even the industrialised ones, would find it too
demanding to cope with some of the control tasks in Nuclear Power Plant,
Petrocemical Process Plant or Railway Signalling at the required level of
dependability for such applications.
> I see PLCs going the way of the panel-box-full of relays. A PC with a
> Controller Area Network doing the work of a PLC as well as data
> aquisition will be the standard in the future.
I think the PLC, as we know it now, will fade into obscurity. However,
there is a new breed of PLC type controllers around which can perform
the data aquisition and control tasks in the harshest of environments.
They are also very networkable and designed to autonomously maintain Safety
Integrity Levels on the equipment they control. At present such systems are
still somewhat bespoke solutions but that is changing slowly.
--
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely
Article: 5839I just read about this in a back issue of EDN magazine (online- December 19, 1996). [ snip ] Metalithic aims Digital Wings for Audio at "prosumers"--professional and private musicians who cannot afford a studio, according to Gilson. The system features 64-voice synthesis (with only two voices currently implemented); software; and an optional, $300 professional breakout box. The company based the system on the "Wingware" reconfigurable-computing system, which comprises an operating system; a tool set; an assembler; a function library that enables reconfigurable computing on FPGAs; and a "nanoprocessor," a Metalithic-patented configurable RISC processor. The nanoprocessor motors through simple operations and uses instruction-set extensions to perform complex processing operations that would otherwise slow a system. Two Xilinx 3090s, each having 320 configurable logic blocks (CLBs), form the processing engine. The basic nanoprocessor takes 28 CLBs, or less than 10%, to instantiate the basic core processor at 50 MIPS, leaving 160 CLBs for Musical Instrument Digital Interface (MIDI), UART, I/O, ISAbus, synthesizer, telephone, and crystal-codec interfaces, along with about 15 instructions. The other 3090 uses a little more than 200 CLBs to provide the vector processor that performs the multiply accumulates, linear interpolation, and table look-up for the synthesizer engine. [ snip ] I am curious to know if anyone else has been able to instantiate a basic 50 Mips processor in less than 10% of a 3090, or a "vector processor" in a little more than 200 CLBs. Is there some big secret about the 3090 you guys have been keeping quite, or is there something I am missing here?Article: 5840
Hi, I am currently doing some research into the efficiency of cryptographic algorithms in reconfigurable hardware and need some libraries to do so. I am currently working with Xilinx XC4020E using WorkView 7.2/XACT 6.0.1 and Altera EPF10K30 using MaxPlusII 7.1. I would like to be able to synthesize my designs into a Lattice architecture, but the libraries that (I thought) were supposed to come with PDS+ for WorkView aren't on the ISP CD-ROM that I received (Or are they?) I have placed a question to Lattice Semiconductor directly but they havn't replied and I'm in a rather urgent need. I need to finish my thesis by May :(. If anybody can clue me in as to whether these libraries are available somewhere, I would be most appreciative. Thanks in advance! -gmh -- Gregory M. Haskins Research Assistant bruman@wpi.wpi.edu CAIS Laboratory ECE Dept Grad Student Worcester Ma Worcester Polytechnic Inst. (508)831-5757 http://leonie.wpi.edu/bruman http://ece.wpi.edu/Research/cryptArticle: 5841
hakk@cent.com (Garnet Brace) wrote: >I don't know about the rest of you guys but personally, I hate >being confined to a single source for any part. Amen. I can see why the manufacturers avoid it. But it causes lots of problems where I work. We design large machines for a relativly low volume market. It takes a long time to get a payback on a design. We are accustom to a product life cycle of 10 to 15 years. Meaning that we can't afford to continously re-engineer our product. On the other hand, the technical requirements of the new products require that we use some leading edge (and sole sourced) parts. Talk about being caught between a rock and a hard place... A practical solution may be for semiconductor companies to place a design in escrow. If company X would drop the part, burn down, etc., company Y could then begin manufacturing the part. This would make my life simpler. And we would use more of the newer parts. A win-win situation???Article: 5842
Gavin Hurlbut (gjhurlbu@beirdo.uplink.on.ca) wrote:
> Unforunately again, our lab group is having a real painful time of trying
> to get our design to work on the BORG board. It simulates perfectly in
> Compass-DA (both the VHDL synthesized and backannotated versions), but
> does not operate AT all on the hardware... We are going to talk to the
> lab tech for the course tomorrow. But I am rambling as usual :) Sorry.
> I shall go to bed now. G'night.
We found the problem at long last. The BUFGP buffers we were using were
not being used correctly. We removed them and just used the combinational
signals, and it works great. The max clock the BORG board is capable of
(in our lab setup at least) is 8 MHz, and our design worked perfectly at
that speed after removing the BUFGPs.
So on to making our design more sleek :)
Ciao.
--
Gavin J. Hurlbut gjhurlbu@beirdo.uplink.on.ca
4B Electrical Engineering ---------------------------------
University of Waterloo School sucks.
My Homepage: http://amprgate.uwaterloo.ca/~gjhurlbu/
Article: 5843In article <01bc34c8$a1e53d30$0a2e36ce@infinity>, Kent <address_withheld@my.discression> wrote: >I am curious to know if anyone else has been able to instantiate a basic 50 >Mips processor in less than 10% of a 3090, or a "vector processor" in a >little more than 200 CLBs. Is there some big secret about the 3090 you >guys have been keeping quite, or is there something I am missing here? Well, if the processor is only some simple control logic and no more (likely), it could easily run at 50MHz. Similarly, I could envision some filters (with fixed multiplies and adds) for 8 or 16 bit quantities fitting fairly well. It is designed for signal processing, and might have been good at it except for two major problems: WAAAY too much hype, and NO I/O bandwidth. The hype is obvious, the bigger problem is that it is an ISA bus card. So all the computing bandwidth in the world doesn't do any good! Who CARES how much processing they can get out of those two 3090s, when you cant get the data into the card? Redone with some bigger gate arrays on a PCI card with real bandwidth, it might be an interesting product. -- Nicholas C. Weaver "Trouble will come in its own time. It always nweaver@cs.berkeley.edu does. But that's tomorrow. Give me http://www.cs.berkeley.edu/~nweaver/ today and I will be happy." It is a tale, told by an idiot, full of sound and fury, .signifying nothing.Article: 5844
Hi,
a generic PCI controller is currently under development at our
institute.
Has somebody done this with ALTERA EPLDs/FPGAs and which chip
was used? Contains the design only the target or master and target?
Thanks for all hints
Wolfram Seibold
--
-----------------------------------------------------------------------------
!ACHTUNG ADRESSAENDERUNG! !NEW
ADDRESS!
-----------------------------------------------------------------------------
Universitaet Stuttgart University of Stuttgart
Institut fuer Nachrichtenvermittlung Institute of Communication
und Datenverarbeitung Networks and Computer
Engineering
Prof. Dr.-Ing. Dr. h. c. P. J. Kuehn Prof. Dr.-Ing. Dr. h. c. P. J.
Kuehn
Pfaffenwaldring 47 Pfaffenwaldring 47
70569 Stuttgart 70569 Stuttgart
Germany
Wolfram Seibold
Tel. : +49 711 685 7965
Fax : +49 711 685 7983
EMail: seibold@ind.uni-stuttgart.de
WWW : http://www.ind.uni-stuttgart.de/IND/MA/Se/
-----------------------------------------------------------------------------
Article: 5845>Some of the math here is getting out of hand. A mathematical "proof" >that one cannot even build a shift register with a common clock just >shows that the assumptions are wrong, since such designs are working by >the millions. Quite. In fact a shift reg merely assumes that the clock skew is less than the clock-Q propagation delay. This is easily achieved when using global clock nets, but very hard when the clock is routed through switches. It actually used to be easy to achieve with e.g. the old 3064 but not with the 3064A. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 5846
In article <peter-1903971555490001@appsmac-1.xilinx.com>
peter@xilinx.com "Peter Alfke" writes:
> In article <5go10m$3c4@maggie.ionsys.com>, hakk@cent.com (Garnet Brace) wrote:
>
> > I don't know about the rest of you guys but personally, I hate
> > being confined to a single source for any part.
>
> The days of second-sourcing state-of-the-art devices are over. The major
> manufacturers see no benefit in it.
>
Well, where possible we _do_ favour parts with second source available - for
example where we could we used XC3000 series because of the second source (AT&T
- whoops I mean Lucent). Even now we still get a stern talking-to by the
buyers when we design-in single-source parts. Of course we still do, as many
parts are not second sourced these days, but if one is it tends to be favoured
(all other things being equal!).
--
-----------------------------------------------------------------------------
| Andrew Morley, Design & Development, Trend Communications Ltd, High Wycombe.|
| email: andrew.morley@trendcomms.com Phone +44 1628-524977 Bucks, UK.|
-----------------------------------------------------------------------------
Article: 5847
Thomas D. Tessier wrote:
>
> Check out Veribest at http://www.veribest.com
>
> They are currently OEMing FPGA Express and have a very good PCB tool.
>
> Have fun.
>
I am currently using VeriBest Designer for Windows NT. At this time
I have only the design capture and simulation parts (well, ok, design
management part too, but I don't use it much). I am looking forward to
trying the synthesis pieces soon. Currently I let the client or the
vendor do the synthesis using Synopsis.
At the time I decided on VeriBest I compared it to View Logic's ASIC
Archetect package for Work View (early '95). A couple of things turned
me off; lack of a static timing checker and database incompatibility
with Pro View. I really didn't look at Cadence or Synopsis because
these packages cost more than my house!
--
IMPORTANT NOTE: reply to scottydm@codenet.net NOT aol.com
___
/////\\ Digitally Enhanced Portrait of:
{|-0-0-|} Scott D. Miller,
| % | Silicon Mercinary
\===/ Freelance Chip Designer
¯
always #5 FOO = ~FOO; // the sound of a beating heart
Article: 5848In article <5gd0vp$4cp@mtinsc03.worldnet.att.net>, c-d-symes@worldnet.att.net says... > >In article <01bc30ac$e2c746b0$0307e38f@zimbo>, > "Joel Kolstad" <Joel.Kolstad@Techne-Sys.com> wrote: >>> any experience with Accolade-Tools (VHDL-Simulation and FPGA-Synthesis) ? >> >>I downloaded their demo and it died a horrible death under NT 4.0. >> >And it's REAL unstable under W95 My 3.06b none limited evaluation copy works fine under Win95. It does have some problem, like sometimes you get multiple minimize/maximize close buttons, and its got some other "features", but it never crashed my machine. Under NT 3.51 the screen is not updated correctly when running PeakSIM. To solve this problem you have to minimize/maximize your screen or zoom in/zoom out. Accolade is bringing out updated quite regularly. Sure it can not compete with V-Systems but than again V-Systems has been around a lot longer than Accolade and is not in the same price range. If you do have a problem, send them to Accolade Technical support and if they ignore you than you know were to complain :-) Hans. SSTL UKArticle: 5849
Two posts for Research Assistants are available at Oxford University to work on the the project "Rapid Implementation of Fieldbus-Compliant, Standalone Self-Validating Instruments". This is a collaboration between the Hardware Compilation Group in the Computing Laboratory and the Sensor Validation Group in the Department of Engineering Science. This work continues a previous successful collaboration which used Hardware Compilation techniques for building complex Self Validation Sensors. Further details are available at: http://www.comlab.ox.ac.uk/oucl/users/ian.page/hwcomp/valcard2/advert.html
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