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 hoped, after reading the headline and the first sentence, that we get it in 6.1... Look like we have to wait another year... BTW: Regarding best CPU, I think that cache-size matters. Thomas "wallge" <wallge@gmail.com> schrieb im Newsbeitrag news:1160750978.838935.193430@b28g2000cwb.googlegroups.com... > So I asked Altera when they would release a version of Quartus that > would support multi-threaded > place and route (this takes the most time on the designs I have worked > on) > I also asked them about the best (fastest) PC to run quartus on. > here's my questions followed by their answers. > ------------------------------------------------------------------------------------------------------------- > Q: > at the end of year I am thinking of purchasing a new PC to do my > quartus > and EDA development on. I was wondering how the system requirements > will change with the release of vista, and what the ideal system > configuration for > running fast synthesis and place and route will be. Right now I am > having to wait between > 15 minutes and two hours for various designs to compile. What system > components will most contribute to faster place and route and synthesis > (eg, more ram, more processors, faster ram, faster processors, 32 vs 64 > bit > architecture?, any specific CPU more highly rated then others?) > > A: > Altera does not have recommendations for CPUs/Mother Board. About the > choice for AMD or Intel processor, Altera does not have testcases to > show one way or another. > > However, the compile time is mostly related to CPU speed and physical > memory size. For detailed information on memory requirements for > compilation targeting different device architectures, please refer to > the readme file by clicking Quartus II menu "Help -> Readme File". > > If system memory is enough and Quartus II don't use hard disk as > virtual memory, you could try to upgrade your CPU speed for good > performance. However, if memory is not enough and hard disk virtual > memory is frequently used, the compilation time will increase more. > Therefore, I think we could firstly satisfy the physical memory > requirement of Quartus II compilation and then try to upgrade CPU > speed. > > Multi processor system or multi-thread CPU will help you run other > applications at the same time as running the Quartus II compile, but > not necessarily will help with the compile time. > > Quartus II can support 64 bit system. Generally, 64 bit Quartus II can > run faster than 32 bit if memory is adequately large (> 2G). However, > the performance upgrade is dependent on specific design project and we > can't provide detailed benchmark. > > 64-bit Quartus II version 6.0 can be installed in UNIX Workstations > (64-bit) (Solaris 8 and 9 only) or Linux Workstations (64-bit > AMD64/EM64T processors) (Red Hat Enterprise Linux 3.0/4.0 WS 64-bit for > AMD64/EM64T only). > ------------------------------------------------------------------------------------------------------------------- > Q: > when will quartus be certified as being windows vista compatible, and > is a 64 bit windows/vista version planned? > > secondly, with the rise of multicore and multiprocessor systems, > is work being done to parallelize the algorithms for synthesis and > place and > route in order to achieve speed benefits available through > multiprocessor systems as they become the norm in the PC market. > > A: > I can't provide the exact schedule about Quartus II certification on > Windows Vista. It's also due to the maturity of the OS. However, > Altera software surely can support those operations systems if they are > popular. > > Our roadmap for Quartus II software also includes multi thread or > multiprocessor system support. However, the release schedule is also > not determined by now. But it might be no later than the end of next > year. Thanks for your understanding. > -------------------------------------------------------------------------------------------------------------------------- >Article: 110301
Peter Alfke schrieb: > Just to clarify the situation: > Antti had ordered the evaluation board for Virtex-5, and Xilinx has > acknowledged and I suppose has shipped the order on Sept 27. > Now let's see how soon it reaches Antti in Munich, Germany, > (Antti please report to the newsgroup when it arrives. > It should not take weeks, the airplane hasn't that much fuel!) > Also, the present version of EDK already supports that board (with > minor wrinkles). > Let's then listen to the continuation of this story... > Peter > ====================== I have ML501 on the desk here! aArticle: 110302
Hi Jacko, We have a list of engineering consulting companies that might be helpful. It's here: http://www.electronicdesignnet.com/cms/component/option,com_ebg/Itemid,92 /task,cos/eid,21312.19328.19442/ You do need to register to get their contact info from ElectronicDesignNet, or alternatively you could just Google for their web site. Although they appear under the "Test & Measurement" category, I believe that some of them are more general. Let me know if that's at all helpful. If not, I may be able to come up with some other ideas. Best, Patrick Webmaster, http://www.ElectronicDesignNet.comArticle: 110303
On Oct 13 (Friday the thirteenth) Antti reports that he has the ML501 board on his desk in Munich. That makes it just a bit over 2 weeks after placing the order. Not bad! Peter Alfke ====================================== Peter Alfke wrote: > Just to clarify the situation: > Antti had ordered the evaluation board for Virtex-5, and Xilinx has > acknowledged and I suppose has shipped the order on Sept 27. > Now let's see how soon it reaches Antti in Munich, Germany, > (Antti please report to the newsgroup when it arrives. > It should not take weeks, the airplane hasn't that much fuel!) > Also, the present version of EDK already supports that board (with > minor wrinkles). > Let's then listen to the continuation of this story... > Peter > ====================== > Antti wrote: > > Antti schrieb: > > > > > Peter Alfke schrieb: > > > > > > > You can order Virtex-5 devices from your distributor now, and he will > > > > offer short delivery times. > > > [...] > > > > Peter Alfke, who has been working on and with these parts for over a > > > > year. > > > > > [my own ***** snipped] > > > until both the silicon AND tools are available there is no supprort. > > > So no matter how ready we may be for Virtex-5, and belive me some > > > of us really are - we are not really able todo any real work until > > > tools support is also made available by Xilinx. > > > > > > > EDK 8.1 SP1 has Virtex-5 MicroBlaze 5.00.a and 5.00.b in it > > it is just labelled as "early access" but its readily available. > > there is some minor mess with MPD files like FSL bus is not > > supported (eg requires manual edit of the MPD) but otherwise > > the Virtex-5 can be targetted ok on EDK 8.1 SP1, eg no need > > to wait for SP2 > > > > here is the picture of the EDK system with Virtex-5 > > > > http://www.microfpga.com/joomla/index.php?page=shop.browse&category_id=12&option=com_virtuemart&Itemid=26 > > > > AnttiArticle: 110304
Nobody would make a major product announcement on Friday the thirteenth... ;-) Peter Alfke =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D GaLaKtIkUs=99 wrote: > Most onnounces are made by Xilinx on monday, perhaps next monday? > > Antti wrote: > > Antti schrieb: > > > > > http://www.sierraic.com/pnresults.asp?part=3DXC5VLX50T1FF1136CES > > > > > > there is status "available" - and full order code as well ! > > > > > > surprisingly Xilinx website doesnt even list device codes for V5LX(T) > > > devices yet. > > > > > > to what I understand all T parts (LXT, SXT and FXT) have 4 TEMACs and= 1 > > > PCIe MAC > > > > > > Antti > > > > !? virtex-5 LXT PCIe has passed PCISIG compliance testing as well !! > > see here > > > > http://www.pcisig.com/developers/compliance_program/integrators_list/pc= ie/ > > > > so I assume the parts are actually obtainable already? > >=20 > > AnttiArticle: 110305
Peter Alfke schrieb: > On Oct 13 (Friday the thirteenth) Antti reports that he has the ML501 > board on his desk in Munich. > That makes it just a bit over 2 weeks after placing the order. Not bad! > Peter Alfke > ====================================== Peter, the order wasnt placed immediatly so that the actual delivery time was below 2 weeks actually. Antti PS but ML505 is still not orderable or is it?Article: 110306
Peter Alfke schrieb: > Nobody would make a major product announcement on Friday the > thirteenth... ;-) > Peter Alfke > ======================== ROTFL, sure ! only Virtex-5 boards may arrive in some countries where the post still works ;) AnttiArticle: 110307
Hey, I've been reluctant recently on envisaging a Virtex-4 device as being operational in a battery-powered situation. The inrush configuration current, high static power consumption, and the non-uniform power exhibited subject to temperature rise are amongst few to name about the shortcomings of SRAM FPGAs in general. Having said that, the unprecedented versatile reconfigurable processing power is yet the decisive factor in prototyping intensive DSP operations. My question is: has any body come across a scenario in which a large FPGA was battery-powered. I'm in the phase of deciding on solutions to employ for my active research so it's quite critical. I don't want to start my research with a major gap in my rationale. Can any veteran in here comment on the topic please. Is it really ridiculous to think about powering a large SRAM FPGA from a battery? Would really appreciate all comments. What's the cheapest price ever a smallest Virtex-4 device was reported? Cheers, -MannyArticle: 110308
Hi, I need a help in static timing analysis for DDR interface to network processor . Processor say that its timing is as per JEDEC standard. For Read i will be use tSD (avg.) =3D (tDQSQ + tDV) =F7 2 and able to find the setup margin and the hold margin. But in the Write i am not able to calculate the same. Controller and DDR SDRAM say that it will provide/need 0.45 ns setup and hold time. I donot have any margin in that case. Can you let me know how do the do timing analysis for the write cycle. =20 Thanks and regards PinkuArticle: 110309
Manny schrieb: > Hey, > > I've been reluctant recently on envisaging a Virtex-4 device as being > operational in a battery-powered situation. The inrush configuration > current, high static power consumption, and the non-uniform power > exhibited subject to temperature rise are amongst few to name about the > shortcomings of SRAM FPGAs in general. Having said that, the > unprecedented versatile reconfigurable processing power is yet the > decisive factor in prototyping intensive DSP operations. My question > is: has any body come across a scenario in which a large FPGA was > battery-powered. I'm in the phase of deciding on solutions to employ > for my active research so it's quite critical. I don't want to start my > research with a major gap in my rationale. Can any veteran in here > comment on the topic please. Is it really ridiculous to think about > powering a large SRAM FPGA from a battery? Would really appreciate all > comments. What's the cheapest price ever a smallest Virtex-4 device was > reported? > > Cheers, > -Manny I was considering V4 lately for portable battery powered gadget and did not see it feasible (different reasons). for you it all depends 1) how much battery power you have 2) what else except FPGA takes power 3) required battery operation time 4) what FPGA is doing the best for battery is V4-FX12 when used with PPC (less power than MB!) every other Virtex4 or Virtex5 means more static power to the extent that it drains the battery on static current only! smallest power an V4FX12 based system takes is about 1W so if your battery has 3w/hr then it will operate 3 hours. pricing - thumb guess ia that if you are would be able to get prices below 70USD you would not be asking. So expect pricing between 70 and 100 AnttiArticle: 110310
Manny, here would be my order of concern: 1. How much, and what type of, logic do I need 2. How fast should it run (can I time-division multiplex?) 3. What is the smallest and cheapest device that fits those requirements 4. How much power does it draw while working, and in stand-by 5. In-rush current is not a concern anymore, and batteries are actually very good at supplying lots of current for a very short time. Virtex-4 LX 15 and '25 and '40 are the smallest, for Virtex-5 it is presently the LX50 Really small devices with Virtex-like features and performance are not in high demand. Most low-end applications do not require that many features and that much performance, and they use Spartan-3 devices. For very low complexity and power consumption, use CoolRunner CPLDs. Peter Alfke, Xilinx Applications =============== Manny wrote: > Hey, > > I've been reluctant recently on envisaging a Virtex-4 device as being > operational in a battery-powered situation. The inrush configuration > current, high static power consumption, and the non-uniform power > exhibited subject to temperature rise are amongst few to name about the > shortcomings of SRAM FPGAs in general. Having said that, the > unprecedented versatile reconfigurable processing power is yet the > decisive factor in prototyping intensive DSP operations. My question > is: has any body come across a scenario in which a large FPGA was > battery-powered. I'm in the phase of deciding on solutions to employ > for my active research so it's quite critical. I don't want to start my > research with a major gap in my rationale. Can any veteran in here > comment on the topic please. Is it really ridiculous to think about > powering a large SRAM FPGA from a battery? Would really appreciate all > comments. What's the cheapest price ever a smallest Virtex-4 device was > reported? > > Cheers, > -MannyArticle: 110311
Hi to everyone, I'm using an Actel fuse A54SX72A, which has 2012 sequential cells and at the moment I filled it up to more than 90%. There can be the need more triple-redundant registers in it and I'm afraid I will have routing problems with that. Has anyone here experienced this? Can I rely on the Actel Designer backannotate to have a close-to-reality simulation? Thanks a lot -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 110312
"Manny" <mloulah@hotmail.com> wrote in message news:1160755594.427130.118490@m73g2000cwd.googlegroups.com... > Hey, > > I've been reluctant recently on envisaging a Virtex-4 device as being > operational in a battery-powered situation. The inrush configuration > current, high static power consumption, and the non-uniform power > exhibited subject to temperature rise are amongst few to name about the > shortcomings of SRAM FPGAs in general. Having said that, the > unprecedented versatile reconfigurable processing power is yet the > decisive factor in prototyping intensive DSP operations. My question > is: has any body come across a scenario in which a large FPGA was > battery-powered. I'm in the phase of deciding on solutions to employ > for my active research so it's quite critical. I don't want to start my > research with a major gap in my rationale. Can any veteran in here > comment on the topic please. Is it really ridiculous to think about > powering a large SRAM FPGA from a battery? Would really appreciate all > comments. What's the cheapest price ever a smallest Virtex-4 device was > reported? > > Cheers, > -Manny Keep in mind that non-nuclear submarines are run on batteries and they tend to use significantly more power than a Virtex-4. What you're willing to use for batteries will determine whether you can achieve your goals. It seems that increasing battery technology has a practical upper limit for ultra-portables. If you have a battery-powered cell phone, running 60 watts through the device would make it unusuable because of the heat genereated in the confined footprint. If you're not going for ultra-portable or single AA-cell powered devices, your options are wide open. Consider that a small Virtex-4 has lower power requirements than the laptop's processor alone.Article: 110313
Manny, Just one comment: There has been no "in rush" or "bonus" current needed since Virtex II (V2, V2P, V4, V5 have no "inrush" for Vccint, the datasheet specifies the minimum Iccint required to power on and configure). What you describe was common for Virtex E, and older families. However, we decided that was unacceptable, so we fixed it (a long time ago, now). Austin Manny wrote: > Hey, > > I've been reluctant recently on envisaging a Virtex-4 device as being > operational in a battery-powered situation. The inrush configuration > current, high static power consumption, and the non-uniform power > exhibited subject to temperature rise are amongst few to name about the > shortcomings of SRAM FPGAs in general. Having said that, the > unprecedented versatile reconfigurable processing power is yet the > decisive factor in prototyping intensive DSP operations. My question > is: has any body come across a scenario in which a large FPGA was > battery-powered. I'm in the phase of deciding on solutions to employ > for my active research so it's quite critical. I don't want to start my > research with a major gap in my rationale. Can any veteran in here > comment on the topic please. Is it really ridiculous to think about > powering a large SRAM FPGA from a battery? Would really appreciate all > comments. What's the cheapest price ever a smallest Virtex-4 device was > reported? > > Cheers, > -Manny >Article: 110314
Manny, Further: http://www.xilinx.com/prs_rls/2006/end_markets/0644_gendynamics.htm It seems that GD has selected V4 for a software defined radio, and it is portable (battery operated). One nice thing about a radio application is that it is not operating continuously (as they are shooting at one another on the battlefield). Another useful element of the JTRS SDR radio is that is does not even load the configuration for a particular modulator or demodulator until it receives, or wishes to transmit in that mode. Only one "waveform" is ever active at a time, and only as transmit, or as receive, and other than that, the FPGA is (probably) powered down and waiting. (I profusely apologize for any marketing contained in this posting: any such marketing content should be considered as such, and treated accordingly.) Austin Manny wrote: > Hey, > > I've been reluctant recently on envisaging a Virtex-4 device as being > operational in a battery-powered situation. The inrush configuration > current, high static power consumption, and the non-uniform power > exhibited subject to temperature rise are amongst few to name about the > shortcomings of SRAM FPGAs in general. Having said that, the > unprecedented versatile reconfigurable processing power is yet the > decisive factor in prototyping intensive DSP operations. My question > is: has any body come across a scenario in which a large FPGA was > battery-powered. I'm in the phase of deciding on solutions to employ > for my active research so it's quite critical. I don't want to start my > research with a major gap in my rationale. Can any veteran in here > comment on the topic please. Is it really ridiculous to think about > powering a large SRAM FPGA from a battery? Would really appreciate all > comments. What's the cheapest price ever a smallest Virtex-4 device was > reported? > > Cheers, > -Manny >Article: 110315
icegray@gmail.com wrote:
> Hi everbody,
> I wanna implement VGA core at 1024x768x75Hz (15" LCD Monitor) on
> Spartan3E starter kit. I have got a few question. I have tried to find
> some detialed documents for VGA timing But I can't. There are 640x480
> and 800x600 but there is no document for more resolution and refresh
> rate.
> - Front porch time, back porch time, and sync pulse times are same at
> every resolution (I think it's standard because VGA cards can change
> resulation and refresh rate for every value and every monitor??? But
> There are different values for 640x480 and 800x600 on the documents???)
> - What is hsync and vsync polarisation? What must I do if it's negative
> or positive? (invert the sync signal???) Why it is different for
> different resolution?
> - Any body can give me timing values or recommend any source? ( I can't
> a right document on the Vesa web page)
>
> Thanks
>
I know this doesn't answer the question exactly, but here are the
parameters I used in my VGA controller for a 60Hz refresh rate:
"1024x768_60Hz": // pixel clk 65MHz
begin
H_FRONT_PORCH=24; HSYNC_WIDTH=136;
H_BACK_PORCH=160; LEFT_BORDER=0; LINE_WIDTH=1024;
RIGHT_BORDER=0; V_FRONT_PORCH=3; VSYNC_WIDTH=6;
V_BACK_PORCH=29; TOP_BORDER=0; FRAME_HEIGHT=768;
BOTTOM_BORDER=0; SYNC_POLARITY=0;
end
You can probably use the same parameters but just bump up the pixel
clock frequency to 80MHz or so.
-Kevin
Article: 110316Thanks Antti, already thought so but i was not sure if thats the good approach. i was puzzled because of the fact that it was working fine with 6.3i. thanks for the help Antti wrote: > avion...@gmail.com schrieb: > > > Hi, > > though not directly releated to the topic but i have similar problem > > with webpack ise. > > the follow code runs ok on 6.3i but fails on 8.2i. can anyone help me > > out why its so and whats the solution? > > > > addr_r <= unsigned(addr_nxt(15 downto 1)); > > addr_r is declared unsigned(22 downto 0) while addr_nxt is > > std_logic_vector(15 downto 0) > > i have also included libraries as : > > library ieee; > > use ieee.std_logic_1164.all; > > use ieee.std_logic_arith.all; > > use ieee.std_logic_unsigned.all; > > use ieee.numeric_std.all; > > with exactly the same files, this code compiles ok on ise 6.3i but > > gives error on 8.2i, the error is that actual size is 23 while the > > operand on right hand side has size 16. > > > > thats correct (by ISE 8.2) it does more checks - > just add the (15 downto 0) to the lefthand operand > should work then > > AnttiArticle: 110317
Thanks a lot guys, all comments are really useful and I'm definitely gonna reason much about them. My application is definitely gonna be DSP intensive. The bad news is that it's basically a CDMA application so many things have to run in parallel in a multiple access system, the more things can run in parallel the more robust the model is and thus yielding in terms of performance. The good news is that we'r not talking about RF signals in here, so things doesn't need to run real fast. My major concern is that things are quite coupled at the moment i.e. lots of things depends on stuff that are yet to be fully characterized. As we might have settle for less perfect hardware (not talking digital in here), our model would grow more complicated as to accommodate for these imperfections. The online reconfigurability of the system is also highly desirable as functionality can change in time. So a CPLD won't do, not even a low-cost spartan although ultimately we might have to sacrafice reconfgurability. The only bright side in this mess is that I might be able to argue, once the system has been fully developed, that certain functionalities have to be ported to ASIC. I'm keen on having as much DSP power as possible as there are advanced issue on the agenda such as Doppler Effective and AOA estimation. So there is no doubt that I'll end up time sharing the available DSP slices. For prototyping, I think it always make sense to get a bit more than what you expect to use. Virtex-4 FX12 seems a reasonable start with the open possiblity to migrate to V-5 once the rest of the family is introduced. Cheers, -MannyArticle: 110318
Antti wrote: > Stepping back ISE history and installing 7.x then 6.x ...etc and > retesting in the hope that maybe > some older version works is really painful :( VMware Server is gratis and once you've gotten your first Windows VM, the next 1,000,000 are easy :-) VMware can use the host filesystem, thus you can just set up a VM for each version of ISE etc. and try them one by one. TommyArticle: 110319
icegray@gmail.com wrote: > Also do you have any idea for polarization??? At a certain point you just need to try and see what the result is. When you get close, you can probably figure out the error from the sort of distortion you see. Also most modern monitors (and all LCD's) do a lot of interpretation of the incoming signal, so things like polarity are likely either autodetected or available in a settings menu. (Though depending on how the on screen display is done, you may not be able to see the settings menu if you have an input signal that is close enough to be recognized as a signal, but not good enough to produce a stable picture.)Article: 110320
pinku1979@gmail.com wrote: > Hi, > I need a help in static timing analysis for DDR interface to network > processor . Processor say that its timing is as per JEDEC standard. > > For Read i will be use > tSD (avg.) = (tDQSQ + tDV) ÷ 2 > and able to find the setup margin and the hold margin. > > But in the Write i am not able to calculate the same. Controller and > DDR SDRAM say that it will provide/need 0.45 ns setup and hold time. I > donot have any margin in that case. Can you let me know how do the do > timing analysis for the write cycle. > > Thanks and regards > Pinku > Tell us: 1. The exact processor 2. The memory you are using 3. The speed you desire to run at and then we might be able to help. I do know that write cycle timing is easier to meet than read for standard DDR memory. Cheers PeteSArticle: 110321
:) Antti wrote: > avionion@gmail.com schrieb: > > > Thanks Antti it works! > > but i still wonder what the lattice people are doing. no response in > > more than a month time. > > Antti wrote: > > > avionion@gmail.com schrieb: > > maybe their webmaster is learning at Xilinx? > > AnttiArticle: 110322
Indeed, that was what i was doing until now ... i just hoped that somewhere there was a constraint that you could use to keep it unoptimized .... thanks anyway ... kind regards, Tim Antti wrote: > Tim Verstraete schrieb: > >> Hey, >> >> I have 2 LVDS clock signals and both are terminated with the DIFF_TERM >> attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them >> ... now i want both buffers to stay in my design and not optimized >> away. Is there a constraint that i can place on that buffer? i guess >> that it should be a UCF constraint since when i look into the RTL >> viewer of planahead and ISE i still see the buffer. >> >> I know that there is an option in NGBuild -u which keeps the unused >> logic, but i do not want to use it just for that 1 buffer ... >> >> thanks in advance, >> >> kind regards, >> >> tim >> >> p.s. i'm using ISE8.2SP2 and a V4SX55-FF1148C > > the best thing possible is to use it without using it :) > 1) like route the unused input to non-bonded IO, > 2) or use in some net in way that the signal isnt really used but XST > fails to optimize it out > 3) or if you dont use BSCAN you can also route it to TDO pin > > all those tricks would keep the net alive. sure it would use > some interconnect resources. > > Antti >Article: 110323
Austin Lesea schrieb: > Manny, > > Just one comment: > > There has been no "in rush" or "bonus" current needed since Virtex II > (V2, V2P, V4, V5 have no "inrush" for Vccint, the datasheet specifies > the minimum Iccint required to power on and configure). > > What you describe was common for Virtex E, and older families. However, > we decided that was unacceptable, so we fixed it (a long time ago, now). > > Austin > Austin, please check Xilinx publication EN049(v 1.3) page 2 for Virtex-5 power requirements during configuration AnttiArticle: 110324
Hello Isaac, > > I am currently in my 3rd year of Electrical Engineering undergrad at > Ryerson University in Toronto, Ontario, Canada. The internship (if > acquired) is slated to start right after this academic year. > This effectively delays my graduation by 1 yr, but I think that is a > really small price to pay for the experience. > Absolutely! We need grads that have practical skills. I have seen many (far too many) who can't even solder. It's pathetic these days. > > Here is a rudimentary list of my skills, a more thorough one will be > submitted w/ my resume: > > Programming Languages: C, Java, Visual Basic, Assembly, Win32 > programming, Python > > Compilers/Environment: GNU tools, Microsoft Visual Studio > > Microprocessors/Microcontrollers: M680x0, Z80, x86, 8051, PIC, MSP430, > ARM7, HC11, Renesas SuperH series > > proemulator.sf.net > > I ported my Z80 emulator to this app some time ago. My M68000 emulator > is working and is tested to be quite accurate, but the author no longer > maintains it or updates it so I decided against porting it (even though > I can still get into the CVS). > > > Programmable Logic: Xilinx Spartan3 series FPGA w/ Xilinx ISE WebPack > > I designed a simple VGA frambuffer 320x240x2-bit and a simplistic > 16-bit CPU in VHDL. > > > Electronics: Basic analog electronics (FET's, OpAmps, BJT's, etc.) > Here all I did was some school projects. Simple stuff: VCO's, FET amps, > etc. > > Operating Systems: Linux, MS-DOS, Windows (effective w/ all). > Been doing installs on all OS's for quite some time now. Used MS-DOS > while I was growing up (had it first running on a 16Mhz 386SX). > > Most the stuff I have learned was from buying products containing the > previously mentioned items and playing around with them and their > associated tools and reading my dads old college books (he studied > electronics engineering technology at NAIT. They did extensive course > work in digital electronics). > > I really do not have any related engineering experience. I did work for > GO Transit this past summer, a major transportation company here in > Ontario, as general help. I was called on one day to look over some > computer scans of microfilm schematics of the trains (and electrical > systems) to make sure they were up to par. > > I would like to shadow some teams in the engineering sector to get a > feel of what you guys do in the industry. I would like to see how you > guys solve problems, tackle issues or shortcomings you come up in > development and the like. I'd also like to learn from the people > working in this industry in general since they have a wealth of > knowledge and experience. Sometthing I think can be invaluable to me in > my career. > > They have some listings at my school, but they are not exactly what I > am interested in. Thanks for listening to my story! > > Any companys you know of in Toronto? Just a suggestion: Post again under the subject "Looking for internship near Toronto". And also post in sci.electronics.design. There are a few Canadians who know the industry up there. Monster might be another avenue (though I don't know if that one is free). Relocation: I wouldn't exclude other places. All my vacation jobs during my university time were actually in other countries. Sometimes I pooled my available rent money with a few others and then we found we were able to rent a nice big house. Almost cost me less than my apartment near the university. And you don't have to live off cans and ramen noodles. It is amazing what you can cook out of fresh ingredients, from scratch, if you have critical mass (enough cash contributing eaters). We took turns shopping and usually cooked together. Pizzas, casseroles and what not, all from scratch and for little money. Yep, we made our own dough. I never ate any fast food from the first day at the university until they handed me my masters. Still don't :-) -- Regards, Joerg http://www.analogconsultants.com
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