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
yusufil...@gmail.com wrote: > linnix wrote: > > We can book a 7 days cruise from LA to Mexico and do hand-on > > training/experiments with FPGA. How many are coming? > > Can you post more information about place, price, dates,concept etc.. 7 days cruise would be: Los Angeles, Cabo San Lucas, Mazatlan, Puerto Vallarta, Los Angeles But we probably would not leave the ship anyway, since rooms and foods are excellent on-board. We can look into interfacing portable instruments with Micro/Avr (always on) to FPGA/Xilinx (on and off), including issues such as power regulations and monitorings, battery chargings, programmings and debuggings. If time permitted, board layouts and mountings (Micro-lead frames and Ball Grid Arrays).Article: 107526
> Of course, we are not interested in helping anyone design an ASIC, so > you are unlikely to get much in the way of support there. Hmm. I thought that most fpga manufacturers provide a path from fpga to ASIC. Is this not true of Xilinx? > On the other hand, since what we do we consider proprietary, we are not > going to share schematics with you. I understand the importance of proprietary intellectual property, as a patent owner, better than most. However, it seems that keeping your customers in the dark about what they are programming is counterproductive. What are Xilinx's real risks? And have they been ripped off in the past? Brad Smallridge aivision > Austin > > Brad Smallridge wrote: >> I wrote down a similar question about >> some skinny rectangles on the perimeter >> of a SX35. These seem to connect to >> the connecting wires and have the funny >> names OMUX, DOUBLE, and HUNIHEX. Any >> idea about what these are? >> >> If the editor does not show us the reality >> of the physical spaces in the silicon as >> Austin has suggested that's fine with me. >> I can speculate on how some features >> might be too small to show graphically. >> >> However, where can one find out about the >> real sizes of the fabric? Curious minds >> will want to know if they are planning future >> ASIC designs or might want to suggest to Xilinx >> some future designs. >> >> Brad Smallridge >> aivision >> dot com >> >> "Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message >> news:ecv54t$6jr$1@news.lysator.liu.se... >>> If I look in the FPGA editor there seems to be one element >>> in the CLB of a Virtex-4 that is odd as compared to previous >>> FPGA generations that I have looked at in the FPGA editor. >>> >>> The CLB looks something like this in ASCII art: >>> >>> +-------------+ >>> | | +--+ >>> | | | | >>> | | | | +-----+ >>> | | | | |SLICE| >>> | | | | | | >>> | | | | +-----+ >>> | | | | >>> | | | | +-----+ >>> | | | | |SLICE| >>> | | | | | | >>> | | |??| +-----+ >>> | Switchbox | |??| >>> | | | | +-----+ >>> | | | | |SLICE| >>> | | | | | | >>> | | | | +-----+ >>> | | | | >>> | | | | +-----+ >>> | | | | |SLICE| >>> | | | | | | >>> | | | | +-----+ >>> | | | | >>> | | +--+ >>> +-------------+ >>> >>> >>> The box with question marks just seems to rearrange the wires so that >>> they are grouped according to function at the switchbox. >>> Is that all there is to it? >>> >>> /Andreas >> >>Article: 107527
John_H wrote: > KJ wrote: > >> Austin Lesea wrote: >> >>> Rick, >>> >>> Via in pad (basically no trace) is best. Placement is not critical, as >>> long as you have via in pad, and planes. >>> >> My memory is fuzzy on this (and other topics for that matter) but I >> think via in pad creates an assembly issue because the pad of the part >> is physically blocking the via (by design). Unfortunately I don't >> recall the specifics, maybe someone else recalls. >> >> Unless you already understand the issue (that I've conveniently >> forgotten) I would suggest that whoever is going to be building your >> boards be consulted to understand if there are appropriate tradeoffs >> that can be made prior to planning to use 'via in pad' since >> manufacturability is also generally a concern that at least must be >> taken into consideration and evalutated. >> >> KJ > > > Via in pad is a bad thing if you don't have filled vias since they would > otherwise wick the solder away from the component. This "solder thief" > can present a reliability problem beyond initial build because of > trapped gasses even if the connection started out as good. > > Filled vias are an extra process that will cost a little money but most > PC vendors can do it. The benefits in lower inductance can be great. Filled vias have an additional cost/risk, and BGAs are already a yield hot spot. What I have seen, is what I'd call tangent vias : these overlap the pads, so that the hole is just under the solder mask. There is no trace. Some CAD tools can also enable/disable Via sharing. Sharing is good for packing more tracks in, but poor for lowest impedance. ( fewer parallel paths result ) In extreme cases, more than one via could be beneficial, but that would impact routing channels. -jgArticle: 107528
rickman wrote: > John_H wrote: >>I've seen good information on Cadence tools based on Sun Microsystems work >>that tracks what you've described with Ritchey. A recent Howard Johnson / >>Xilinx talk also covered many of these items well without contradiction. > > > The contradiction part I don't agree with. Many still argue that the > distance between the IC and the cap is critical and some still say > quantity is more important than variety of SRF. It depends on the PCB topology: For BGA, that is not true, as you (should) go the the plane first. For 2 layer PCBs, with QFP packages, then the distance between cap and IC is certainly critical :) -jgArticle: 107529
mikegurche@yahoo.com wrote: > rickman wrote: > > mikegurche@yahoo.com wrote: > > > In synthesis, the problem is normally the abuse of sequential > > > statements, rather than the use of variable. I have seen people trying > > > to convert C segment into a VHDL process (you can have variables, for > > > loop, while loop, if, case, and even break inside a process) and > > > expecting synthesis software to figure out everything. > > > > Personally I think most problems in using HDLs in this way come not > > directly from the way signals or variables are used, but rather from > > the use of an HDL to describe the solution in an abstract way. I > > nearly always design in terms of registers and "clouds" for the logic. > > I get a feel for how large the design is and if I need to optimize at > > this block diagram level. I can even get an idea of how complex the > > logic part is by looking at the equations that describe it. Then I use > > an HDL to "describe" the hardware rather than describing the > > functionality and letting the tool decide what hardware to invoke. > > > > I agreed with you completely. What I am trying to say is that variable > may not be synthesizable if you write the code with a "C > mentality." I'm not sure I agree that variables are the problem at all. There are many ways to write code that is not synthesizable. This can be done with signals as well as variables. The difference between signals and variables is just that the value of a variable is updated immediately just like a 'C' variable. Signals are only updated at the end of the process. So if you make an assignment to a variable and then use that value in a calculation in the same process, the new value will be used. If you do the same thing with a signal, the old value of the signal will be used. I don't know of a way that this can be unsynthesizable. Variables can not exist outside of a process, IIRC. So the variable must be assigned to a signal in order for it to affect anything outside the process. So in reality, it can only be used as an intermediate value in an assignment to a signal. Do you have an example of unsynthesizable code using a variable that would be synthesizable with a signal?Article: 107530
Walter Banks wrote: > Jim, > > We have certainly thought about it. Byte Craft has done quite a bit of > instruction design work on embedded commercial processors. Internally > for every C compiler we create an instruction set simulator with a lot of > performance instrumentation. > > I expect the next round of processors will move towards multiple processor > solutions to applications. Compilers and other HLL tools will be focused on > application work division. > > w.. Sounds promising. What about debug pathways ? -jgArticle: 107531
Richard Henry wrote: > We have been encouraged to spend some of our remaining training budget > by taking a week-long seminar in September. I am looking for something > concerning FPGA design, wireless networks, or just general engineering. > My preference would be somewhere in southern California, but other > places may be negotiable. > > Any suggestions? If it were me, I'd save it for the Paris airshow (:Article: 107532
Jim Stewart wrote: > Richard Henry wrote: > > > We have been encouraged to spend some of our remaining training budget > > by taking a week-long seminar in September. I am looking for something > > concerning FPGA design, wireless networks, or just general engineering. > > My preference would be somewhere in southern California, but other > > places may be negotiable. > > > > Any suggestions? > > If it were me, I'd save it for the Paris airshow (: Fiscal year ends Sept 30.Article: 107533
Brad, Good questions. I will attempt answering them, -snip- >> Of course, we are not interested in helping anyone design an ASIC, so >> you are unlikely to get much in the way of support there. > > Hmm. I thought that most fpga manufacturers provide a path from fpga to > ASIC. Is this not true of Xilinx? There are companies who use our parts to verify the logic prior to its placement in an ASIC. Good business, as they buy our largest parts, and lots and lots of them. We make no further effort to help them create ASICs. We appreciate their use of our parts, even if that use leads eventually to less business. >> On the other hand, since what we do we consider proprietary, we are not >> going to share schematics with you. > > I understand the importance of proprietary intellectual property, as a > patent owner, better than most. However, it seems that keeping your > customers in the dark about what they are programming is counterproductive. > What are Xilinx's real risks? And have they been ripped off in the past? Then you can appreciate that customers have trust in Xilinx not to do anything to make it trivial, or easy, for their clever IP to be ripped off. As for being ripped off in the past, we have not been harmed per se, but customers have been harmed by a company cloning an entire pcb, and then copying the eproms, and selling that product for less money. I won't say who did this, as it is all litigated and settled now, and Xilinx derives benefit because both companies bought our FPGAs (the cloning company had to, as they had no means to modify or change the design, or even to fix any bugs). This is why today we offer the bitstream decryption features in V2, V2Pro, V2Pro-X, V4, and now V5. We will do whatever we can to help protect the customer's investment. What you refer to as "Keeping our customer's in the dark" is in no way a hindrance, or a handicap, as reverse engineering is perfectly legal to fix a problem, or discover how something works. We do not keep our customer's in the dark for a legitimate reason. If someone has to reverse engineer something (for example: a soft error broke their design, which line of VHDL did that bit affect?) we are happy to work with them to resolve the issue by telling them exactly what they need to know (in fact, we will parse their design, and use our tools to discover what they require). AustinArticle: 107534
Jim Granville wrote: > Any info out yet on what MAX3 looks like ? > Does it improve Static Icc, and lack of memory of MAX II, for example ? > Smallest devices / largest devices ? Nope - Altera's silicon design team is quite busy with Cyclix III. If you have any good suggestions on specs outside the hobby sphere, now might be a good time to post them... BenArticle: 107535
Thanks for your help guys, that fixed it. Interesting that the EDK
system assembly GUI doesn't hook up clock and reset by default...
Cheers,
David
G=F6ran Bilski wrote:
> David wrote:
> > G=F6ran Bilski wrote:
> >
> >
> >>David wrote:
> >>
> >>>Hi all,
> >>>
> >>>I'm trying to implement a correlator as a coprocessor on the FSL bus.
> >>>The first thing I've done is generate the FSL example using the create
> >>>peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze. When
> >>>I do a blocking write or read the MB stalls - my understanding is that
> >>>this will happen if the FSL FIFO is full or empty respectively, but it
> >>>happens the first time I write to it, so the FIFO should not be full.
> >>>
> >>>If I use non-blocking reads and writes and check the error and invalid
> >>>flags after each one using fsl_isinvalid() and fsl_iserror() - see code
> >>>below - everything seems normal but the output is always zero. Am I
> >>>implementing the error checking macros correctly?
> >>>
> >>>
> >>>#define write_into_fsl(val, id) nputfsl(val, id)
> >>>#define read_from_fsl(val, id) ngetfsl(val, id)
> >>>
> >>>#define WRITE_FSL_TEST_0(val) write_into_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
> >>>#define READ_FSL_TEST_0(val) read_from_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
> >>>
> >>>
> >>>void fsl_test_app(
> >>> unsigned int* input_0, /* Array size =3D 2 */
> >>> unsigned int* output_0 /* Array size =3D 2 */
> >>> )
> >>>{
> >>> int i;
> >>> Xuint8 is_error =3D 0;
> >>> Xuint8 is_valid =3D 0;
> >>>
> >>> print("Entering fsl_test_app \r\n");
> >>>
> >>> //Start writing into the FSL bus
> >>> for (i=3D0; i<2; i++)
> >>> {
> >>>
> >>> WRITE_FSL_TEST_0(input_0[i]);
> >>> fsl_iserror(is_error);
> >>> xil_printf("error post: %d \r\n", is_error);
> >>> fsl_isinvalid(is_valid);
> >>> xil_printf("valid post: %d \r\n", is_valid);
> >>> }
> >>> print("Finished Write \r\n");
> >>>
> >>> is_error =3D 0;
> >>> is_valid =3D 0;
> >>>
> >>> //Start reading from the FSL bus
> >>> for (i=3D0; i<2; i++)
> >>> {
> >>> READ_FSL_TEST_0(output_0[i]);
> >>> fsl_iserror(is_error);
> >>> xil_printf("error post: %d \r\n", is_error);
> >>> fsl_isinvalid(is_valid);
> >>> xil_printf("valid post: %d \r\n", is_valid);
> >>> }
> >>>}
> >>>
> >>>I added external ports to the FSL core to check the reset polarity and
> >>>monitor the state machine - the core is not being held at reset, but
> >>>always sits in the Idle state. This, coupled with the blocking
> >>>instruction problems seems to indicate an issue with the FSL FIFO
> >>>perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
> >>>If anyone has any ideas on what might be going wrong your help would be
> >>>much appreciated...
> >>>
> >>>
> >>>Cheers,
> >>>
> >>>David
> >>>
> >>
> >>Hi,
> >>
> >>Can you show the .mhs where you have connected your FSL core with
> >>Microblaze?
> >>
> >>G=F6ran Bilski
> >
> >
> >
> > Hi G=F6ran,
> >
> > Thanks for your reply, here are the relevant parts of the .mhs file:
> >
> > BEGIN microblaze
> > PARAMETER INSTANCE =3D microblaze_0
> > PARAMETER HW_VER =3D 4.00.a
> > PARAMETER C_USE_FPU =3D 0
> > PARAMETER C_DEBUG_ENABLED =3D 1
> > PARAMETER C_NUMBER_OF_PC_BRK =3D 2
> > PARAMETER C_FSL_LINKS =3D 1
> > BUS_INTERFACE DLMB =3D dlmb
> > BUS_INTERFACE ILMB =3D ilmb
> > BUS_INTERFACE DOPB =3D mb_opb
> > BUS_INTERFACE IOPB =3D mb_opb
> > BUS_INTERFACE SFSL0 =3D fsl_v20_0
> > BUS_INTERFACE MFSL0 =3D fsl_v20_1
> > PORT CLK =3D sys_clk_s
> > PORT DBG_CAPTURE =3D DBG_CAPTURE_s
> > PORT DBG_CLK =3D DBG_CLK_s
> > PORT DBG_REG_EN =3D DBG_REG_EN_s
> > PORT DBG_TDI =3D DBG_TDI_s
> > PORT DBG_TDO =3D DBG_TDO_s
> > PORT DBG_UPDATE =3D DBG_UPDATE_s
> > END
> >
> >
> > BEGIN fsl_v20
> > PARAMETER INSTANCE =3D fsl_v20_0
> > PARAMETER HW_VER =3D 2.00.a
> > PARAMETER C_EXT_RESET_HIGH =3D 0
> > PARAMETER C_IMPL_STYLE =3D 1
> > END
> >
> > BEGIN fsl_v20
> > PARAMETER INSTANCE =3D fsl_v20_1
> > PARAMETER HW_VER =3D 2.00.a
> > PARAMETER C_EXT_RESET_HIGH =3D 0
> > PARAMETER C_IMPL_STYLE =3D 1
> > END
> >
> > BEGIN fsl_test
> > PARAMETER INSTANCE =3D fsl_test_0
> > PARAMETER HW_VER =3D 1.00.c
> > BUS_INTERFACE MFSL =3D fsl_v20_0
> > BUS_INTERFACE SFSL =3D fsl_v20_1
> > PORT reset_out =3D fsl_test_0_reset_out
> > PORT state_debug =3D fsl_test_0_state_debug
> > END
> >
> > Cheers,
> >
> > David
> >
>
> Hi,
>
> You need to connect the system clock to the fsl_v20 modules.
> They are non clocked right now.
>
> One good trick is always to look at the top level vhdl file in the hdl
> directory. It's called system.vhd
>
> In that file you will see what signals are connected to what and it this
> case you should be able to see that the fsl bus doesn't have any clock
> connected.
>=20
> G=F6ran Bilski
Article: 107536"rickman" <gnuarm@gmail.com> wrote in message news:1156880090.634821.118390@i3g2000cwc.googlegroups.com... > > I'm not sure what you are asking. A different capacitance will not > change the inductive part of the impedance curve and a different > inductance will not change the capacitive part of the curve. What > changes in both cases is the SRF. So you put a few 0.1 uF caps on the > board and a number more of 0.01 uF caps and even more of the 0.001 uF > caps. Each capacitance value needs to have sufficient quantity to > bring the impedance near the SRF low enough to be effective. Then the > capacitive effect of the smaller caps keep the overall impedance low in > spite of the larger caps being inductive. Finally the impedance of the > ground planes keep the impedance low for the highest frequency. Doing > a simulation is always a good thing to be able to see how the parallel > resonances affect the impedance. > > > The contradiction part I don't agree with. Many still argue that the > distance between the IC and the cap is critical and some still say > quantity is more important than variety of SRF. In one of these > threads there was a link to a post by HJ. There were some things in > the HJ post that were not supported by any sort of measurement or even > simulation. I don't recall the details. > > > Not inductance, impedance. I don't care about inductance if I can keep > the impedance low over the frequency range that matters to my design. > The small deltas in inductance only move the SRF, they don't have a > large impact on the impedance after you mix the capacitor values. > So, here's my thoughts. If we have two caps of different values, but the same package/inductance, there's a frequency between the SRF of the caps that has a parallel resonance which leads to a peak in the impedance. For example, C1, a 1uF 0402 has a SRF of 10MHz. C2, a 0.1uF 0402 has a SRF of 25MHz. Between 10 MHz and 25MHz, C1 looks inductive and C2 capacitive. This means there's a peak in the impedance. So, the stragegy of using different values to 'even out' the impedance gives us peaks (bad) and troughs (good) in the impedance across the frequency spectrum. However, for a 0.1uF 0402 cap, at resonance the ESR is 0.014R, so the Q of the tuned circuit is about 5. For a 0402 1uF cap, the ESR at resonance is 0.01R, giving a Q of 2. These values of Q are so low as to make the self resonance problem/advantage make bugger all difference. Note that a 10nF 0402 cap has a Q of about 3 at its SRF of 70MHz. BTW, I got the cap data from here http://www.murata.com/designlib/mcsil.html (Also, note that the vias/traces to connect these caps probably double the inductance, reducing the SRF by 30%) As for the 'plane capacitance', it starts to have an effect at frequencies > 1GHz which is a fat lot of good when our vias and BGA balls have inductances in the nH region. Remember, we're not trying to bypass the power plane, we're trying to bypass the IC. In conclusion, mixing different values of ceramic caps in the same packages might help a little but might hurt a little in a real system with FPGAs. I maintain that using the biggest value in the size you choose is the best, if nothing else because they have the crappest Q and this avoids BOM bloat. If we do use a range, bully for us, we probably won't notice any difference, but we have more chances for resonance and EMI failures. Finally, I agree that the positioning of the cap is of lesser importance. However, some of us prefer not to waste layers in our stacks on power planes, we prefer to have decent grounds and route our FPGA power on layers used for signals in other places. The HF plane capacitance is pissed away by the chip mounting interconnect anyway, and its high Q might lead to evil resonances. (As you mention in your posts, Rick.) In this case, with little mini-planes for power routing, capacitor placement is crucial. (Note. With FPGAs needing at least 3 supplies, and maybe a lot more, the PCBs are getting very expensive with planes for every supply.) In conclusion, for FPGA PCBs, Lots of ground layers, one for every two signal layers. One value of cap per size. Use lots of caps. It means less impedance. Power planes only need extend as far as the bypass caps. So, closer the caps to the target device, the less plane needed. IMHO, YMMV, HTH, Syms. p.s. It's easy to simulate this stuff, try the excellent and free LTSpice from http://www.linear.com/company/software.jsp (as recommended by Bob, thanks!) p.p.s. Let me underline, _other_ways_work_too_ , but I'm happy with this methodology, and I don't think other solutions work noticeable better.Article: 107537
On 29 Aug 2006 14:56:12 -0700, in comp.arch.embedded "Richard Henry" <pomerado@hotmail.com> wrote: > >Jim Stewart wrote: >> Richard Henry wrote: >> >> > We have been encouraged to spend some of our remaining training budget >> > by taking a week-long seminar in September. I am looking for something >> > concerning FPGA design, wireless networks, or just general engineering. >> > My preference would be somewhere in southern California, but other >> > places may be negotiable. >> > >> > Any suggestions? >> >> If it were me, I'd save it for the Paris airshow (: > >Fiscal year ends Sept 30. Change your OS......... martinArticle: 107538
Brad Smallridge wrote: > The bit-banging is probably slower. > > How are you handling your IOs? > > You may wish to use tristate outputs > with your signals going to the T input: > > scl_iobuf : IOBUF > port map ( > O => open, > IO => scl_pin, > I => '0', > T => scl_master ); > > sda_iobuf : IOBUF > port map ( > O => sda_slave, > IO => sda_pin, > I => '0', > T => sda_master ); > > Brad Smallridge > aivision > dot com Even after applying the IP core and driver patches described in Xilinx Answer 23866, I still have the same problem. What could cause the core to skip a bit/clock within a transfer that is atomic at the user-level?Article: 107539
Hi Gabor, Thank you for your prompt reply. I am using Altera Stratix development board (pro edition 1s40) for this project. The board provide around 40k of LEs, and my whole design is only taking 15k of all. Do you think it's likely there is a power supply drop ? (by the way I am not sure how to check if there is power drop or not. :P ) > Also when reducing the SDRAM clock, make sure you don't violate > the refresh period requirements. Normally refresh timing is done by > counting clock cycles, I looked up the default timing setting for my sdram controller (I build my design based on the example design provided by Altera) in SOPC builder and all timing are specified in seconds except the "initialisation refresh cycles". Since cycle period increase when the frequency is lowered, the timing setting in seconds will end up the same no matter how I change the clock frequency?. Thank you TonyArticle: 107540
"Symon" <symon_brewer@hotmail.com> wrote in message news:44f4c58b$1_1@x-privat.org... > > p.s. It's easy to simulate this stuff, try the excellent and free LTSpice > from > http://www.linear.com/company/software.jsp > (as recommended by Bob, thanks!) > Here's a simple LTSpice file with a swept frequency across two caps. It's interesting to experiment and see where the resonances occur. Version 4 SHEET 1 1316 756 WIRE 0 464 -208 464 WIRE 208 496 144 496 WIRE 336 496 288 496 WIRE 384 496 336 496 WIRE 448 496 384 496 WIRE 464 496 448 496 WIRE -208 512 -208 464 WIRE 336 560 336 496 WIRE 448 560 448 496 WIRE 0 592 0 560 WIRE -208 624 -208 592 WIRE 336 736 336 624 WIRE 448 736 448 624 FLAG 0 592 0 FLAG -208 624 0 FLAG 336 736 0 FLAG 384 496 Vcap FLAG 448 736 0 SYMBOL SpecialFunctions\\modulate 0 464 R0 WINDOW 3 0 0 Invisible 0 SYMATTR InstName A1 SYMATTR Value MARK=40000000 SPACE= 5000000 SYMBOL voltage -208 496 R0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V1 SYMATTR Value PULSE(0 1 100ns 1us 1us 1us 4us) SYMBOL res 304 480 R90 WINDOW 0 0 56 VBottom 0 WINDOW 3 32 56 VTop 0 SYMATTR InstName R2 SYMATTR Value 0.1 SYMBOL cap 320 560 R0 SYMATTR InstName C2 SYMATTR Value 0.1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1 SYMBOL cap 432 560 R0 SYMATTR InstName C5 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 TEXT 144 344 Left 0 !.tran 20usArticle: 107541
rickman wrote: > If nothing else you can check out the > Ritchey book, "Right The First Time, A Practical Handbook on High Speed > PCB and System Design, Volume 1". He is promising a Volume 2, > "Included in this text will be a thorough treatment of EMI; a > comprehensive description of the PCB fabrication process and PCB > materials; a detailed examination of simulation tools and their use and > a complete discussion of Gigabit and higher signaling protocols." awesome ... thanks for the pointer ... ought to make some interesting bed time reading ;)Article: 107542
On Tue, 29 Aug 2006 14:56:12 -0700, Richard Henry wrote: > Jim Stewart wrote: >> Richard Henry wrote: >> >> > We have been encouraged to spend some of our remaining training budget >> > by taking a week-long seminar in September. I am looking for something >> > concerning FPGA design, wireless networks, or just general engineering. >> > My preference would be somewhere in southern California, but other >> > places may be negotiable. >> > >> > Any suggestions? >> >> If it were me, I'd save it for the Paris airshow (: > > Fiscal year ends Sept 30. Oh, hell, then: They've _GOT_ to spend the money - just make something up! For a price, I can give you a week-long seminar in just about anything you want to study! Good Luck! RichArticle: 107543
On Tue, 29 Aug 2006 13:38:55 -0700, linnix wrote: > yusufil...@gmail.com wrote: >> linnix wrote: >> > We can book a 7 days cruise from LA to Mexico and do hand-on >> > training/experiments with FPGA. How many are coming? >> >> Can you post more information about place, price, dates,concept etc.. > > 7 days cruise would be: > > Los Angeles, Cabo San Lucas, Mazatlan, Puerto Vallarta, Los Angeles > > But we probably would not leave the ship anyway, since rooms and foods > are excellent on-board. > > We can look into interfacing portable instruments with Micro/Avr > (always on) to FPGA/Xilinx (on and off), including issues such as power > regulations and monitorings, battery chargings, programmings and > debuggings. If time permitted, board layouts and mountings (Micro-lead > frames and Ball Grid Arrays). How hard would it be to carry a couple of ozs of Acapulco Gold back from the cruise? Like, does Customs pat you down or use dogs or anything? Or do they just assume that anyone who can afford a week-long cruise has better things to smuggle than pot? ;-) Thanks! RichArticle: 107544
Symon, I am using 2002 laptop PC. I am trying to use Matlab to input data from the parallel port. Sending data using Matlab works fine. Thanks, Dan Symon wrote: > Dan, > Which parallel port signals are you trying to read? On old parallel ports, > the data pins can only be outputs from the PC. > Cheers, Syms. > > "EEngineer" <maricic@gmail.com> wrote in message > news:1156804493.078190.57560@74g2000cwt.googlegroups.com... > > PC, the voltage is 3.3V which seems OK. But why I can not read anything > > on my PC from the parallel port? > > > > Thanks, > > Dan > >Article: 107545
Rich Grise, Plainclothes Hippie wrote: > On Tue, 29 Aug 2006 13:38:55 -0700, linnix wrote: > > yusufil...@gmail.com wrote: > >> linnix wrote: > >> > We can book a 7 days cruise from LA to Mexico and do hand-on > >> > training/experiments with FPGA. How many are coming? > >> > >> Can you post more information about place, price, dates,concept etc.. > > > > 7 days cruise would be: > > > > Los Angeles, Cabo San Lucas, Mazatlan, Puerto Vallarta, Los Angeles > > > > But we probably would not leave the ship anyway, since rooms and foods > > are excellent on-board. > > > > We can look into interfacing portable instruments with Micro/Avr > > (always on) to FPGA/Xilinx (on and off), including issues such as power > > regulations and monitorings, battery chargings, programmings and > > debuggings. If time permitted, board layouts and mountings (Micro-lead > > frames and Ball Grid Arrays). > > How hard would it be to carry a couple of ozs of Acapulco Gold back from > the cruise? Like, does Customs pat you down or use dogs or anything? Or do > they just assume that anyone who can afford a week-long cruise has better > things to smuggle than pot? ;-) You do have to go through airport like security. They don't want you to sink the ship or bring in foreign plants (fruits and pot included) to the state. > > Thanks! > RichArticle: 107546
Phil James-Roxby wrote: > That said, its understandable that people see SATA and immediately think > hard drives. We tried in the documentation to explain the difficulty > of connecting to drives, for example, on page 67 of the user guide, we > stated Hi Phil, People have a right to get upset when you advertise/describe one thing, and deliver something completely different. Consider selling 74LS02 chips and calling them PLD's or FPGA's. Sure, you have a fine bit serial prototype bench, SATA shouldn't be anywhere in ANY document unless it's standard conforming product.Article: 107547
Martin Thompson wrote: > Can I suggest you stick the docs up on the actualy web somewhere, last > time I looked, they were all in SVN. I checked them out and there was > some very interesting stuff in there, but I imagine most people would > like to have a read of what you have more easily than that... The doc's are available under the Doc page, which are Beta-2 docs. Current work in progress will be always SVN. I try update the doc's as we check things in, so it's not a frenzy at the next beta freeze. > Are you going to start making use of the carry chain... last time I > tried a counter, it didn't go anywhere near it, just a big lump of > LUT4s - took me right back to uni, doing next-state logic > minimisations for a counter! There isn't really any technology specific generation at the moment, so it doesn't use the LUT carry resources. In fact, the current internal technology makes it nearly impossible. That is something that we are addressing soon ... probably Beta-4 > Have you considered doing a higher-level technology independent > VHDL/Verilog backend, which could then be thrown into a normal > synthesizer and let it ifugre out the best adders and such like - > they've been practising that for a number of years now :-) There is a VHDL output, fully functional I believe in Beta-1 ... it got broke in Beta-2, and will be fixed at Beta-3 again (which should be very soon).Article: 107548
OK, here's a LTSpice file that shows a resonance between disimilar cap values. The circuit sweeps from 5MHz to 45MHz back and forth. The first three sweeps are done with two 1uF caps, the second three with a 1uF and a 0.1uF cap. Notice the big resonance at about 10MHz for the second set of sweeps. The performance of the second circuit is slightly better at 45MHz, worse at 5MHz, MUCH worse at 10MHz. HTH, Syms. Version 4 SHEET 1 1516 904 WIRE 1040 432 800 432 WIRE 0 464 -208 464 WIRE 208 496 144 496 WIRE 384 496 288 496 WIRE 448 496 384 496 WIRE 656 496 448 496 WIRE 896 496 656 496 WIRE -208 512 -208 464 WIRE 656 512 656 496 WIRE 896 512 896 496 WIRE 736 528 704 528 WIRE 1040 528 1040 432 WIRE 1040 528 944 528 WIRE 448 560 448 496 WIRE 800 576 800 432 WIRE 800 576 704 576 WIRE 976 576 944 576 WIRE 0 592 0 560 WIRE -208 624 -208 592 WIRE 656 624 656 592 WIRE 896 624 896 592 WIRE 1040 624 1040 528 WIRE 656 720 656 688 WIRE 736 720 736 528 WIRE 736 720 656 720 WIRE 896 720 896 688 WIRE 976 720 976 576 WIRE 976 720 896 720 WIRE 448 736 448 624 WIRE 656 736 656 720 WIRE 896 736 896 720 WIRE 1040 736 1040 704 FLAG 0 592 0 FLAG -208 624 0 FLAG 384 496 Vcap FLAG 448 736 0 FLAG 656 736 0 FLAG 896 736 0 FLAG 1040 736 0 SYMBOL SpecialFunctions\\modulate 0 464 R0 WINDOW 3 0 0 Invisible 0 SYMATTR InstName A1 SYMATTR Value MARK=45000000 SPACE= 5000000 SYMBOL voltage -208 496 R0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V1 SYMATTR Value PULSE(0 1 100ns 1us 1us 1us 4us) SYMBOL res 304 480 R90 WINDOW 0 0 56 VBottom 0 WINDOW 3 32 56 VTop 0 SYMATTR InstName R2 SYMATTR Value 0.1 SYMBOL cap 432 560 R0 SYMATTR InstName C5 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL sw 656 608 R180 SYMATTR InstName S1 SYMATTR Value MYSW SYMBOL cap 640 624 R0 SYMATTR InstName C1 SYMATTR Value 0.1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1 SYMBOL cap 880 624 R0 SYMATTR InstName C3 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL sw 896 608 R180 SYMATTR InstName S2 SYMATTR Value MYSW SYMBOL voltage 1040 608 R0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V3 SYMATTR Value PULSE(1 -1 12us 1ns 1ns 12us 24us) TEXT 144 344 Left 0 !.tran 24us TEXT 296 888 Left 0 !.model MYSW SW(Ron=0.0001 Roff=10Meg Vt=.5 Vh=-.4)Article: 107549
Nevo wrote: > I'm designing a Cyclone device and am having problems with one pin. > > I want to use the configuration pin ASDO as an I/O pin after my device > finishes active serial configuration. I assigned my I/O to that pin but the > fitter barks at me that it "Can't place node ~ASDO~ in location 37 because > location already occupied by Q[0]" > > I went to Assignments... Device... Device & Pin Options... Dual-Purpose > Pins, but the setting for ASDO is greyed out. > > How do I tell Quartus to let me use that pin as an I/O pin after AS > configuration? > > Thanks, > > -Nevo Cyclone does not support the use of the ASDO pin as an I/O after Active Serial configuration. See: http://www.altera.com/literature/hb/cyc/cyc_c51013.pdf Go to page 48 and look for ASDO "User Mode" in the table. Marc
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