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
I had ground the ICs down until I hit the bond wire loops. That's what makes me even more disappointed. :( The reason I keep resorting to emulating the IWM and 8390 is because I'd like the thing to be able to boot MacOS when I'm done. Unless I modified the ROM, I don't see how I could get it to boot. That's why I thought the MFM interface would be helpful. It might show a second entry point for booting. Jim Granville: Which Atmel development kit are you talking about? Do you have a specific one in mind?Article: 78226
nathan wrote: (snip) >>A Schmidt trigger so it doesn't count noise that still comes >>through. Otherwise 60Hz counting isn't too slow, but the >>edge must be faster than that. If you put it through a few >>inverters (and make sure they don't get optimized away) that >>would speed up the transition. > The 60Hz is a square wave output from an opto-isolator. It rises from > 0.6V to 4.7V in 110 microseconds. Is that fast enought? For ACEX 1K, which I have the data sheet sitting here, (the PDF actually) rise time should be 40ns. Though an inverter or two it will likely be that fast. -- glenArticle: 78227
Moti wrote: > I know it should be there, the problem is that it is not there (even > after installing the service pack) ... > I will appreciate it if you will be able to send me the package or at > least the pdf document contained there by email. > Err, sorry but distributing Copyrighted info is not something I am interested in doing. Push your FAE a bit harder. -- My real email is akamail.com@dclark (or something like that).Article: 78228
15th International Conference on
Field Programmable Logic and Applications
August 24-26 Tampere Hall, Tampere, Finland
FIRST CALL FOR PAPERS
FPL is the first and largest conference covering the
rapidly growing area of field programmable logic.
During the past 14 years, many of the advances achieved
in reconfigurable architectures, applications, design
methods and tools have been first published in the
proceedings of the FPL conference series. The 15th FPL
will be hosted by the Institute of Digital and Computer
Systems of Tampere University of Technology, Finland.
CONFERENCE TOPICS
The Program Committee invites you to participate and
submit your contribution to FPL 2005. The conference
topics within the scope of field programmable logic
include, but are not limited to:
RECONFIGURABLE ARCHITECTURES
o Dynamic and run-time reconfiguration
o Low power architectures
o Defect and fault tolerance
o Reconfigurable embedded systems
o Field-programmable analogue arrays
o Interconnects and NoCs
APPLICATIONS
o Communications/networking/cryptography
o Bioinformatics
o Application acceleration
o Evolvable and bio-inspired applications
o Rapid prototyping
DESIGN METHODS AND TOOLS
o CAD for reconfigurable architectures
o Optimisation and technology mapping
o System-level design methods
o Testing, verification and benchmarking
o Hardware/software co-design
o Compilers and languages
SURVEYS, TRENDS AND EDUCATION
o Roadmap of reconfigurable computing
o Teaching reconfigurable systems
o History and surveys of reconfigurable logic
o Emerging device technologies
o Tutorials
SUBMISSION GUIDELINES
Authors are invited to submit original and unpublished
contributions as:
. 10 page papers to be considered as regular
papers or posters
. 2 page extended abstracts for PhD forum
contributions and tutorial proposals
All contributions must be submitted electronically in
PDF format using Springer LNCS Instructions for
Authors. The conference proceedings will be published
and distributed at the time of the conference in the
LNCS series and on CD-ROM. After the conference, the
proceedings will be published in the SpringerLink
online collection. For detailed formatting and
submission information, please visit FPL 2005
conference website at
http://fpl.cs.tut.fi/
IMPORTANT DATES
Paper Submission Deadline: March 14th 2005
Notification of Acceptance: May 23rd 2005
Early Registration Deadline: June 20th 2005
--
T.Rissa
Article: 78229nathan wrote: > The 60Hz is a square wave output from an opto-isolator. It rises from > 0.6V to 4.7V in 110 microseconds. Is that fast enought? No, typically 10-20ns is spec, but upto around 150ns is tolerated. Can you change the opto to a schmitt model ? -jgArticle: 78230
John Cappello wrote: > Austin Lesea <austin@xilinx.com> wrote in message news:<cht42i$6o86@cliff.xsj.xilinx.com>... > > Symon, > > > > Yes, it would. That is a nice trick, but you trade one problem (duty > > cycle) for another, getting a 622 MHz signal into the chip (SI is much > > tougher the higher the frequency). > > > > I think John's problem is more that he has a clock that switches between > > two sources. If the clock must switch, then you best reset the DCM. > > > > Austin > > > > Symon wrote: > > > Austin, > > > If John's used the input divide-by-2 mode, to make 311MHz from 622MHz > > > wouldn't that take care of any duty cycle problems? > > > Cheers, Syms. > > > "Austin Lesea" <austin@xilinx.com> wrote in message > > > news:chprct$73l1@cliff.xsj.xilinx.com... > > > > > >>John, > > >> > > >>There have been cases where the frequency, jitter, and duty cycle are > > >>just on the edge of where the DCM phase detector will operate reliably. > > >> > > >>Check the input duty cycle. It will need to be as close to 50% as you > > >>can make it. The spec is 45 to 55%, but at the higher frequencies, it > > >>may have to be even closer to 50% when you take clock jitter into > > >>account (as if it is 45%, and it has jitter, then it is sometimes less > > >>than 45%!). > > >> > > >> > > >>John Cappello wrote: > > >> > > >> > > >>>Hi, > > >>> > > >>>We are seeing evidence that a DCM is intermittently selecting the > > >>>wrong tap position after it completes its lock sequence after a DCM > > >>>reset pulse. I'd like to know if anyone has experienced this effect, > > >>>and if they were able to resolve this problem. > > >>> > > >>>In a 2v6000, I am using a variable phase shift DCM which is driven by > > >>>a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks > > >>>on its clk0/clk180 output pins. This interface uses IOB DDR regs for a > > >>>622 Mhz/16-bit LVDS transmission solution. > > >>> > > > > > > > > > > > Hi Austin, > I wanted to focus more on the DCM reset. As you may recall, we can fix > or break our system with multiple DCM resets. Whether due to bad clock > or fluctuating voltges, why would you suppose the integrity of the > dcm's output is decided only during this reset sequence? I am confused > because it seems that the DCM is constantly updating its tap position > in response to its phase comparators even during the locked state. > Thanks. > John John Cappello: I was wondering how you solved your problem. I also have a system that behaves like yours, I mean that we can fix or break it with multiple DCM resets. We can even configure DCM for a fixed phase value (not variable) and even then, the problem shows up. 90% of the resets work well and of the resets causes a problem. If we do a "bathtub" (DCM phase shift x BER) using variable DCM phase values and reset at each increment, we can see clearly the "spikes" in our bathtubs, when things go wrong. Looks like something funny in the reset sequence. Am I missing something trivial in the settings of the DCM? I would appreciate any feedback! Rgds, Roberto MattosArticle: 78231
Jim Granville wrote: > nathan wrote: > > The 60Hz is a square wave output from an opto-isolator. It rises from > > 0.6V to 4.7V in 110 microseconds. Is that fast enought? > > No, typically 10-20ns is spec, but upto around 150ns is tolerated. > Can you change the opto to a schmitt model ? > -jg I've been following this thread for a while and still can't figure out why Nathan really wants to use 60 Hz as a clock signal rather than using some higher frequency to sample and debounce it. I never saw a reply to Dan's post on what else is inside the CPLD that would warrant using the part in the first place. Clearly if all you had was a 4 bit count at 1 Hz, you could do the whole job in the cheapest 8-pin PIC micro (PIC12C508 comes to mind) which has an internal 4 MHz oscillator and requires almost no external parts (just decoupling caps). So if the CPLD has something else going on, what is the rest clocked with, and if not why use a CPLD at all?Article: 78232
"-Lance" <Lance@theSillyWorld.com> a écrit dans le message de news: 41f7d60d$1@solnews.wv.mentorg.com... > John David Birch wrote: >> Is there any software I can download for use in MATLAB/Simulink that I >> can download for free for testing / simulating FPGA from Xilinx ? >> >> I am doing my masters degreee thesis. >> > > Have you looked at Simulink's "Link for ModelSim"? > > I am not sure about cost (they may have educational versions). > > -Lance Is it necessarly for Xilinx?? because Altera have a librairy for simulink called "DSPBuilder" that permit to design Altera's FPGA, I already use it durin an internship and it works well links : http://altera.com/products/software/products/dsp/dsp-builder.html i think you could download and use it for free but you should need a licence for some device.(for P&R) AlexisArticle: 78233
Ok, I'm totally confused now. I'm a newbie to this so please bare with me. The project is a line scan camera with a low res encoder that i want to double up / triple etc. The encoder can go from 0hz to 25khz To i count how many system clocks in that period i get ? do i need a ADPLL ? what is a NCO ? Can you describe the basic's Many Regards Pliers "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message news:ct8h48$bgl2@xco-news.xilinx.com... > Falk Brunner wrote: > > "Kevin Neilson" <kevin_neilson@removethiscomcast.net> schrieb im Newsbeitrag > > news:ct66gl$bgl1@xco-news.xilinx.com... > > > > > >>>The Freq of the Altera is 20Mhz > >>>The max freq of the encoder is 25Khz > >>>The max Freq of output is 30Khz > >>> > >>>Please Help. > >>> > >>>Pliers > >>> > >> > >>With such a massive ratio between system freq and encoder freq there is > >>no need for a PLL. Just sample the encoder input using the system clock > >>and add in pulses as desired. > > > > > > ;-)) > > then it would be still a ADPLL. But the goal ist to have the pulses spaced > > as equal as possible. This reqires a ADPLL. > > But after all, even a ADPLL is "just" a clever FSM. > > > > Regards > > Falk > > > You're right. For some reason I was thinking he wanted to use a PLL or > DLL, but he does clearly say he wants an ADPLL. So the correct answer > is: no, I don't have any code for that, but if the input pulse edges > are clean, making an ADPLL should be very straightforward: just make an > NCO and then add a value to the NCO's phase increment that is > proportional to the phase difference between the NCO and the input clock.Article: 78234
"Gary Crean" <a@a.com> schrieb im Newsbeitrag news:M8UJd.1308$Y05.898@newsfe1-gui.ntli.net... > Ok, I'm totally confused now. I'm a newbie to this so please bare with me. Uhhh, a ADPLL isnt neccessary a thing to start with. > The project is a line scan camera with a low res encoder that i want to > double up / triple etc. > > The encoder can go from 0hz to 25khz The encoder frequency (and so the rotation of the belt/drum/whatever is better reasonable constant, otherwise the PLL gets in trouble. > To i count how many system clocks in that period i get ? Yes. > do i need a ADPLL ? Most probably. > what is a NCO ? Same as DCO ;-) NCO = Numerical Controled Oscillator. Regards FalkArticle: 78235
I heard that Lattice Semiconductor Corporation boasted they were providing the lowest-cost FPGA and CPLD solutions, not sure if the news was true. Could anybody confirm it? If so could anybody give me a price range for their lowest-cost solution? I always have an impression that Xilinx provided the lowest-cost chip while Altera provided the high-performance one, is it still true? How is the Lattice compared to Xilinx and Altera? Thanks. Johnson http://www.latticesemi.com/products/index.cfmArticle: 78236
Johnson Liuis wrote: > I heard that Lattice Semiconductor Corporation boasted they were providing > the lowest-cost FPGA and CPLD solutions, not sure if the news was true. > Could anybody confirm it? If so could anybody give me a price range for > their lowest-cost solution? > > I always have an impression that Xilinx provided the lowest-cost chip while > Altera provided the high-performance one, is it still true? How is the > Lattice compared to Xilinx and Altera? "Lowest cost" is nearly always qualified to such an extent, that it is market-droid meanginless. You also need to watch the end of next year / high volume asymptote prices, versus real world (ie now) prices... For example, Altera claim their MAX-II devices are lowest cost, but they have pruned all devices sub 128MC, so their cheapest device is a lot more expensive than others 32 & 64 MC devices, and indeed their cheapest MAX ii is a lot more than their cheapest MAX3000.... What they actually mean is price paid _per_macrocell_ is relatively low, but that does not have the marketing razz.... So, you need to choose the resource you need, & volumes, then get prices on that to compare - and remember to include the Loader/config memory. -jgArticle: 78237
> >I heard that Lattice Semiconductor Corporation boasted they were providing >the lowest-cost FPGA and CPLD solutions, not sure if the news was true. >Could anybody confirm it? If so could anybody give me a price range for >their lowest-cost solution? > >I always have an impression that Xilinx provided the lowest-cost chip while >Altera provided the high-performance one, is it still true? How is the >Lattice compared to Xilinx and Altera? > >Thanks. > >Johnson > >http://www.latticesemi.com/products/index.cfm > > HOO-BOY - strap on your helmets guys, we're in for a rough one - I think we ALL offer the lowest cost, highest performance device - just have a problem with how to draw the lines around the various devices :) Mike T p.s. in the words of Pres Clinton - how do you define is?Article: 78238
Hello Andrea,
Thank for the response. I wrote a simple test pcore to get a feel for how
the plb_ipif module should respond. Below is snippet of the main code. The
summary of the code is that it issues a single beat write to an address,
then issues a read to the same location. There is a little counter that
waits after the reset signals have gone high before it starts the
write/read requests. Note that the BE, Data, Addr, buses etc. are held
constant well before the requests are made. Would you happen to have a
simple example of PLB master you wrote that works? I would like to see the
timing to get an idea why the M_Request and associated plb_ipif signals
are not being triggered. Also, what version of plb_ipif are you using? We
are using plb_ipif_v2_01_a (the one that has a master attachment).
Thanks,
Nju
reg [6:0] counter;
wire counter_done;
// Logic for simple 7-bit coutnter
always @(posedge Bus2IP_Clk)
begin
if(Bus2IP_Reset) counter[6:0] <= 7'd0;
else if (counter < 7'd127) counter <= counter + 1'b1;
else counter <= counter;
end
assign counter_done = (counter == 7'd127);
assign IP2Bus_Data = 64'hfeeddeadbeefbead;
assign IP2Bus_Retry = 1'b0;
assign IP2Bus_Error = 1'b0;
assign IP2Bus_ToutSup = 1'b0;
assign IP2Bus_RdAck = Bus2IP_RdReq;
assign IP2Bus_WrAck = Bus2IP_WrReq;
assign IP2Bus_Addr = 32'h00000008;
assign IP2Bus_MstBE = 8'hf0;
assign IP2Bus_MstBurst = 1'b0;
assign IP2Bus_MstBusLock = 1'b0;
assign IP2Bus_MstNum = 5'h0;
assign IP2IP_Addr = IP2Bus_Addr;
// Logic for requests
// State machine for simple write, followed by read
reg [1:0] state, nxt_state;
//State encoding
parameter COUNTING = 2'b00;
parameter WRITING = 2'b01;
parameter READING = 2'b10;
parameter DONE = 2'b11;
always @(posedge Bus2IP_Clk)
begin
if(Bus2IP_Reset) state <= COUNTING;
else state <= nxt_state;
end
always @(/*AUTOSENSE*/Bus2IP_MstError or Bus2IP_MstLastAck
or Bus2IP_MstTimeOut or counter_done or state)
begin
case(state[1:0])
COUNTING:
nxt_state <= (counter_done == 1'b0) ? COUNTING: WRITING;
WRITING:
nxt_state <= (Bus2IP_MstLastAck | Bus2IP_MstTimeOut |
Bus2IP_MstError) ? READING: WRITING;
READING:
nxt_state <= (Bus2IP_MstLastAck | Bus2IP_MstTimeOut |
Bus2IP_MstError) ? DONE: READING;
DONE:
nxt_state <= DONE;
default: nxt_state <= COUNTING;
endcase // case(state[1:0])
end // always @ (...
assign IP2Bus_MstRdReq = (state == READING);
assign IP2Bus_MstWrReq = (state == WRITING);
On Wed, 26 Jan 2005, Andrea Sabatini wrote:
> Nju,
>
> I've been designing master PLB master modules using the PLB IPIF for quite a
> while now and, like in your case, the only think I could rely on were the
> two diagrams you referreded to in your message and the simulation results. I
> have to say that I did not follow the design flow suggested by Xilinx
> because I just instatiated the PLB IPIF inside my code and I did not use the
> Peripheral wizard.
>
> I think that the timing reported in those two diagrams is not correct
> becasue the signls Bus2IP_Cs and Bus2IP_CE are always asserted at the same
> point in time but the signals Bus2IP_RdCe, Bus2IP_WrCe, Bus2IP_RdReq and
> Bus2IP_WrReq, althought are always asserted at the same time, are alwas at
> least one clock cycles delayed respect to the previous two.
>
> To be honest, I do not think that that module is bug-free but so far it seem
> to behave correctly in our application.
>
> If you can be more specific about your problem maybe I can help you a little
> more.
>
> Regarding the documentation, I do not know if something more detaild exist.
>
> Regards,
>
> Andrea Sabatini
>
>
>
Article: 78239> The reason I keep resorting to emulating the IWM and 8390 is because > I'd like the thing to be able to boot MacOS when I'm done. I reckon you need to start with a working Mac board and replace one PAL at a time.Article: 78240
After over 2 years of waiting Actel has finally announced ProAsic3 Flash-FPGAs with lowest price tag starting 1.5USD They also claim Libero 6.1 supports ProASIC3 Well when I tried Libero 6.1 then it did not work for any selectable PA3 device - and here is reply from Actal, quote "Hi Antti, The programming file generation is disable in this version. Since, you don't have any sample part and this option is not available." So because they (Actel) KNOW that I (Antti) do not have PA3 samples it means it is OK to ship Libero without support of programming file generation and still claim it supports PA3, because I the poor soul would not have any silicon to test with anyway? I probably wanted to see if my STAPL player is compatible with the PA3 programming file generated, and for that purpose I dont need silicon, but need a programming file, right? [auto-censored stuff deleted...] Antti LukatsArticle: 78241
Antti Lukats wrote: > After over 2 years of waiting Actel has finally announced ProAsic3 Flash-FPGAs with lowest price tag starting 1.5USD > > They also claim Libero 6.1 supports ProASIC3 > > Well when I tried Libero 6.1 then it did not work for any selectable PA3 device - and here is reply from Actal, quote > > "Hi Antti, The programming file generation is disable in this version. Since, you don't have any sample part and this option is not available." > > So because they (Actel) KNOW that I (Antti) do not have PA3 samples it means it is OK to ship Libero without support of programming file generation and still claim it supports PA3, because I the poor soul would not have any silicon to test with anyway? > > I probably wanted to see if my STAPL player is compatible with the PA3 programming file generated, and for that purpose I dont need silicon, but need a programming file, right? > > [auto-censored stuff deleted...] :) If that was a genuine excuse, you have a right to feel miffed, but probably the real reason is that the Software is so much in Beta mode, that it hardly completes a task, and they are franticaly trying to sort it.... The above buys them time, without admiting problems. Still, I'd imagine your stapl player would tolerate synthesis bugs in the programming file, so you could go back, and ask them to enable it, and you will promise not to send the results to a real chip.... ? :) -jgArticle: 78242
Antti Lukats wrote: > After over 2 years of waiting Actel has finally announced ProAsic3 Flash-FPGAs with lowest price tag starting 1.5USD > > They also claim Libero 6.1 supports ProASIC3 > > Well when I tried Libero 6.1 then it did not work for any selectable PA3 device - and here is reply from Actal, quote > > "Hi Antti, The programming file generation is disable in this version. Since, you don't have any sample part and this option is not available." <snip> Keep us posted with progress.... These do look like nice devices, remind me of MAX II, but _WITH_ SRAM, which was the glaring oops in MAX II.... Lattice have a FLASH FPGA solution comming as well, 2005 looks to be an interesting year... -jgArticle: 78243
Hi Jim, any more about this lattice info I mean of what you can say ;) I have a bit more about PA3, there: <http://www.openchip.org/mambo/index.php?option=com_content&task=view&id=12&Itemid=1> the OOPS with PA3 is that the blockRAM can not be used as ROM, no init from config, and that the FROM (1k flash array) is not writeable from FPGA only from ext JTAG and MAX2 has no BlockRAM, so interesting what the Lattice thing will be, and what OOPses are there AnttiArticle: 78244
ok, you can try to insert a LCELL primitive behind the redundant gates. Maxplus is not allowed to remove that if synthesis style is set to WYSIWYG.Article: 78245
On Wed, 26 Jan 2005 21:42:04 GMT, "Gary Crean" <a@a.com> wrote: >Ok, I'm totally confused now. I'm a newbie to this so please bare with me. > OK, this post is intentionally written for a newbie audience, so please bear with me if it tells you stuff you already know. >The project is a line scan camera with a low res encoder that i want to >double up / triple etc. > >The encoder can go from 0hz to 25khz >To i count how many system clocks in that period i get ? >do i need a ADPLL ? >what is a NCO ? > >Can you describe the basic's I'll try. I *think* that the abbreviation ADPLL stands for "All Digital Phase Locked Loop". How that differs from DPLL is somewhat beyond me. It sounds like one of those acronyms that were so hideously popular in audio-land a while back, like OCL (Output Capacitor Less). Yuck. Anyhows, DPLLs I kinda understand. Here goes. First I'll try to rehearse the real basics so we can all agree what's going on. You have a linescan camera that's imaging thin strips of something. To get the second dimension of the image, you are scanning the camera past the object or vice versa. This second direction of scan is mechanical and comparatively slow, because the movement during one line-scan readout time must be quite small. To establish precisely how the second direction of scan is moving, you have an encoder or pulse generator somewhere on its mechanics. This encoder is rather coarse, so that you need many scan lines for each pulse it generates. OK so far? Next problem: If your encoder is coarse, it's probably also not very accurate - in other words, its edges or pulses are not very precisely located. So your interpolation between those edges needs to do a certain amount of smoothing-out of the jitter that inevitably comes with low-res encoders. (Think a standard mouse, with its ultra-cheap moulded encoder disks with nasty rough edges on the slots, and fairly poor quality optics on the optical detectors). Both of these issues are nicely dealt with by a phase-locked loop. The idea is that you run a variable-frequency oscillator at the fast (interpolated) pulse rate. Then you divide that oscillator by the interpolation factor. The divided-down oscillator should now be running at exactly the same frequency as your encoder output (but, of course, it won't be). Now you feed both the encoder output and the divided oscillator into a phase comparator, which detects how far adrift the oscillator is with respect to the encoder that it's trying to track. This error signal can then be fed back to modify the oscillator's frequency. In this way the frequency (oscillator/N) is kept exactly in step with the frequency (encoder), so the oscillator is obviously running at (N*encoder). The really tough part of any PLL design is how you process the error signal before using it to control the oscillator's frequency. This aspect of the design is generally known as the "loop filter". Your specific problem is rather hard because of the extremely wide (ratio) range of frequency you must cover - you say 0 to 25kHz, but I guess you don't need real phase-lock performance over anywhere near that range. However, it's also simplified (I hope!) because the encoder is probably attached to a fairly large lump of mechanical doohickey, so its frequency is known to change only very slowly. In the jargon: your PLL needs a very large capture range, but it needs to track frequency changes only quite slowly. The "oscillator" in your digital system is, of course, not an oscillator at all, but some kind of divided version of your system clock which I think you said was about 25MHz. The traditional way to do this is to use a numerically controlled oscillator. Now that I've given you that background, I guess you should be able to Google for some of the following: digital phase comparator numerically controlled oscillator phase locked loop digital phase locked loop lead-lag loop filter and I suspect you'll find more stuff than you know what to do with. Once you've taken a look at it and have got some ideas about how to do your own implementation, you may want to come back here to calibrate your thinking again - there are plenty of folk on this group who have done lots of this kind of thing. Finally, one simple and obvious suggestion that isn't a PLL at all, but may get you to an implementation a bit quicker: Count the time between encoder edges, using a clock that is your system clock divided by your required frequency- multiplication ratio. Now, use that counted time value as the factor in a programmable frequency divider to get a divided-down version of your system clock. The output of this programmable frequency divider will be the encoder frequency multiplied by your required ratio. This method is prone to all manner of errors because it takes no account of encoder jitter, speed variations and so on - but it is very easy to implement, and it may help to get you started. Good luck -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 78246
Antti Lukats wrote: > Hi Jim, > > any more about this lattice info I mean of what you can say ;) Hi Antti, Well, this was the info released on Sept 10th : "In addition, Lattice has recently received the first 130nm Flash-based products and the first 90nm products fabricated by Fujitsu, which are currently in the early stages of evaluation." These are the ones comming after the already released EC/ECP FPGAs. Actel say Q4 for production, so there is time for Lattice to come to the party. Some vendors have long vapor-ware times, and some do not. eg TI came onto the ARM uC scene with merchant TMS470's quite quickly. > I have a bit more about PA3, there: > > <http://www.openchip.org/mambo/index.php?option=com_content&task=view&id=12&Itemid=1> > > the OOPS with PA3 is that the blockRAM can not be used as ROM, no init from config and no serial load, you have to consume FPGA fabric to init... > and that the FROM (1k flash array) is not writeable from FPGA only from ext JTAG that's somewhat understandable. Still, 1K is probably (just) enough to include a tiny-boot-load, so a MUX is not needed in the critical RAM path of a SoftCPU. > > and MAX2 has no BlockRAM, so interesting what the Lattice thing will be, and what OOPses are there Icc and esp the Vcc range specs of PA3 look nice. ie They admit it operates at low Vcc, just not at full speed. Potential for ideas there, but no Icc/Vcc plots yet... The "F" grade is also an interesting idea - looks a bit like the yield failures, in Tpd and Icc, and some apps are really don't care on speed or Icc, so it allows them to ship low price devices. ( hopefully the $1.50 price is not for 'F' grade.. :) ) Nice low Min Freqs on the PLLs too... Good package ranges, but why only the smallest in MLF132 ? ( die too large on the others ? ) -jgArticle: 78247
hello everbody, While drawing new scheme with FPGA or CPLD, Must I care about pin sort? Like as Macrocell 1 should control RAM and Macrocell 7 should control SPI? What should I care about new design?Article: 78248
We apologize if this is a duplicate email. International Conference on Computational Intelligence and Multimedia Applications, August 16-18, 2005 University of Nevada, Las Vegas, USA (www.iccima.org) F I R S T C A L L F O R P A P E R S The International Conference on Computational Intelligence and Multimedia Applications will be held at the University of Nevada, Las Vegas, USA on August 16-18, 2005. The conference will provide an international forum for discussion on issues in the areas of Computational Intelligence and Multimedia for scientists, engineers, researchers and practitioners. ICCIMA05 is organized jointly with International Conference on Systems Engineering (ICSE'05: www.icseng.info) and the registered participants of ICCIMA05 will be able to attend ICSEng05. The conference will include sessions on theory, implementation and applications, as well as the non-technical areas of challenges in education and technology transfer to industry. There will be both oral and poster sessions. Accepted full papers will be included in the proceedings to be published by IEEE CS Press. Selected papers will be published in "International Journal on Computational Intelligence and Applications" published by World Scientific Publishing Company Press. Several well-known keynote speakers will address the conference. Conference Topics Include (but not limited to): Artificial Intelligence Artificial Neural Networks Pattern Recognition Fuzzy Systems Genetic Algorithms Hybrid Systems Intelligent Control Intelligent Databases Knowledge-based Engineering Learning Algorithms Memory, Storage and Retrieval Multimedia Systems Formal Models for Multimedia Interactive Multimedia Multimedia and Virtual Reality Multimedia and Telecommunications Multimedia Information Retrieval Multimedia and Security Multimedia Hardware Multimedia and Algorithms Special Sessions, Pre-Conference Workshops and Tutorial: Proposals for special sessions, pre-conference workshops and tutorials relevant to the conference topics are invited. The deadline for submitting the proposal is Feb 15, 2005. Special Poster Session: ICCIMA'05 will include a special poster session devoted to recent work and work-in-progress. Abstracts are solicited for this session (2 page limit) in camera ready form, and may be submitted up to 30 days before the conference date. They will not be refereed and will not be included in the proceedings, but will be distributed to attendees upon arrival. Students are especially encouraged to submit abstracts for this session. Invited Sessions Keynote speakers (key industrialists, chief research scientists and leading academics) will be addressing the main issues of the conference. Important Dates: Submission of papers received latest on: March 10, 2005 Submission of Papers Papers in English reporting original and unpublished research results and experience are solicited. Electronic submission of papers via www.iccima.org. Visit the web page for more information. Page Limits Papers for refereeing should be double-spaced and must include an abstract of 100-150 words with up to six keywords. Selected papers will have a limit of 6 pages in the proceedings to be published by IEEE. Evaluation Process All submissions will be refereed based on the following criteria by two reviewers with appropriate background. originality significance contribution to the area of research technical quality relevance to ICCIMA 2005 topics clarity of presentation Referees report will be provided to all authors. Check List Prospective authors should check that the following items are attached and guidelines followed while submitting the papers for refereeing purpose. * The paper and its title page should not contain the name(s) of the author(s), or their affiliation * The paper should have attached a covering page containing the following information -title of the paper -author name(s), title, affiliation, mail and e-mail addresses, phone and fax numbers -Conference topic area -up to six keywords * The name, e-mail, phone, fax and postal address of the contact person should be attached to the submission. Contact Information: ICCIMA' 05 Secretariat Department of Electrical and Computer Engineering University of Nevada, Las Vegas 4505 Maryland Parkway, Box 454026 Las Vegas, NV 89154-4026 USA Phone: +1 702 895 4184 Fax: +1 702 895 1115 email: secretary@iccima.org URL: http://www.iccima.org/Article: 78249
We apologize if this is a duplicate email. EIGHTEENTH INTERNATIONAL CONFERENCE ON SYSTEMS ENGINEERING (ICSEng05) LAS VEGAS, USA, AUGUST 16-18, 2005 (http://www.icseng.info) This series of International Conferences is jointly organized on a rotational basis among three institutions, University of Nevada, Las Vegas, USA, Technical University of Wroclaw, Poland, and Coventry University, UK. In August 2005, the 18th International Conference will be held in Las Vegas, NV, at the University of Nevada, Las Vegas, USA. The Proceedings of the conference will be published by IEEE CS. ICSEng05 is organized jointly with the International Conference on Computational Intelligence and Multimedia Applications (ICCIMA'05: www.iccima.org) and the registered participants of ICSEng05 will be able to attend ICCIMA05. Scope of Conference: The Conference will cover the general area of Systems Engineering, with particular emphasis being placed on applications. It is expected to include sessions on the following themes: Avionics Computer Algorithms, Databases, Parallel and Distributed Systems, Networks Digital systems, architecture Control Theory, System Identification and Adaptive Control, Nonlinear Controls Data Fusion Engineered Systems for Nuclear Waste Management Environmental Systems and Energy Systems Expert Systems and Artificial Intelligence Finance Engineering Geographic Information Systems Global Position Systems Information Theory and Communication Systems Neural Network and Applications Requirements Processes Risk Management Robotics and Industrial Automation Systems Engineering Metrics Systems Engineering Paradigms, Standards and Challenges System Architecture Standards and Testing Signal Processing Systems Engineering Education Transportation Systems Submissions: We invite you to submit a one page abstract for the purpose of reviewing by March 10, 2005. Accepted authors will be invited to submit a full paper (6 pages maximum limit) for presentation. All abstracts are to be submitted in PDF, postscript or MS word version electronically. For more information on submissions refer to: http://www.ee.unlv.edu/~selvaraj/icse05/submission/. Please follow the ICSEng'05 guidelines for more information on submission. Submission implies the willingness of at least one of the authors to register and present the paper. All abstracts will be peer reviewed by two independent referees of the International Program Committee of ICSEng'05. Special Session proposals are solicited from those who are interested in organizing a session dealing with a specific area of the conference. Special Session organizers will be members of the Program Committee and will be responsible for advertising, collecting and reviewing technical papers. Due date for submission of Special Session proposals: February 15, 2005. Special Poster Session: ICSEng'05 will include a special poster session devoted to recent work and work-in-progress. Abstracts are solicited for this session (2 page limit) in camera ready form, and may be submitted up to 30 days before the conference date. They will not be refereed and will not be included in the proceedings, but will be distributed to attendees upon arrival. Students are especially encouraged to submit abstracts for this session. Important Dates: Abstracts due: March 10, 2005 Proposals for special sessions due: February 15, 2005 Steering Committee Prof. W. R. Wells (Chair), UNLV, USA Prof. H. Selvaraj, UNLV, USA Prof. Z. Bubnicki, Technical Uni. of Wroclaw, Poland Prof. A. Grzech, Technical Uni. of Wroclaw, Poland Prof. D. J. G. James, Coventry University, UK Prof. K. J Burnham, Coventry University, UK General Chair: Prof. H. Selvaraj, UNLV, USA Program Committee Prof. A. K. Datta, UNLV, USA Prof. A. V. Balakrishnan, UCLA, USA Prof. W. N. Burkov, Russian Acad. of Sciences, Russia Dr. H. S. Cho, Korean AIST, Korea Prof. T. F. Gonzalez, Uni. of California, Santa Barbara, USA Prof. G. Guardabassi, Politecnico di Milano, Italy Prof. A. Gunasekaran, Uni. Of Massachusetts, USA Prof. H. Migliore, PSU, USA Prof. L. Hsu, Uni. Federal do Rio de Janeiro, Brazil Prof. L. Jozwiak, Eindhoven Uni. of Tech, Holland Prof. T. Luba, Warsaw Uni. of Technology, Poland Prof. V. Muthukumar, UNLV, USA Prof. S. Nambisan, UNLV, USA Dr. M. Rawski, Warsaw Uni. of Tech., Poland Prof. H. Selvaraj, UNLV, USA Prof. S. Singh, UNLV, USA Prof. H. Sorenson, UC San Diego, USA Dr. S. Stubberud, The Boeing Company, USA Prof. M. Sugisaka, Oita University, Japan Prof. M. Thoma, Universitat Hanover, Germany Prof. R. Vallee, LUniversite Paris-Nord, France Dr. L. Wang, Harbin U. of Tech., China Prof. W. R. Wells, UNLV, USA Organizing Committee Chair: Prof. V. Muthukumar, UNLV, USA Contact: Conference Secretary, ICSE-2005 Howard R. Hughes College of Engineering University of Nevada, Las Vegas, Las Vegas, NV 89154-4005 Phone: (702) 895 4184 FAX: (702) 895 1115 email: secretary@icseng.info URL: http://www.icseng.info/
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